From emailgrant at gmail.com Fri Mar 6 18:49:15 2015 From: emailgrant at gmail.com (Grant) Date: Fri, 6 Mar 2015 10:49:15 -0800 Subject: [ic] form profiles In-Reply-To: <54EBB166.7070603@pajamian.dhs.org> References: <54EBB166.7070603@pajamian.dhs.org> Message-ID: >> Braintree gives this error when attempting to process a credit card sometimes: >> >> "Postal code can only contain letters, numbers, spaces, and hyphens." >> >> I've only used required/mandatory with mv_form_profile so I'm not sure >> how to set up this sort of a check to work with [error]. Can someone >> point me in the right direction? I seem to remember "zip" in >> etc/profiles.order that I was planning to use as a starting point but >> it isn't there any more. > > So if I understand correctly you want IC to have the same requirement > before the data goes out to Braintree. > > There is zip, ca_postcode and postcode checks but that limits you to US > and Canadian postal codes, see: > > http://www.icdevgroup.org/interchange-doc-5.2.0/frames/ictemplates_36.html > > You probably want the regex check which is documented on the same page > as follows: > > zip=regex ![^A-Za-z0-9 -] "Postal code can only contain letters, > numbers, spaces, and hyphens." Hi Peter, can that go in the mv_form_profile? I tried it there but I get: Sorry, there was an error in processing this form action. Please report the error or try again later. (Unmatched [ in regex; marked by <-- HERE in m/[ <-- HERE ^A-Za-z0-9/ at (eval 205) line 15. ) Also I use email_only in my mv_form_profile but it lets spaces in the email address go through. Where is email_only defined or is there a better definition to use? - Grant From peter at pajamian.dhs.org Fri Mar 6 21:44:43 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 07 Mar 2015 10:44:43 +1300 Subject: [ic] form profiles In-Reply-To: References: <54EBB166.7070603@pajamian.dhs.org> Message-ID: <54FA1FCB.2080004@pajamian.dhs.org> On 03/07/2015 07:49 AM, Grant wrote: >> zip=regex ![^A-Za-z0-9 -] "Postal code can only contain letters, >> numbers, spaces, and hyphens." > > > Hi Peter, can that go in the mv_form_profile? I tried it there but I get: > > Sorry, there was an error in processing this form action. Please > report the error or try again later. (Unmatched [ in regex; marked by > <-- HERE in m/[ <-- HERE ^A-Za-z0-9/ at (eval 205) line 15. ) Try quoting the regex: zip=regex "![^A-Za-z0-9 -]" "Postal code can only contain letters, numbers, spaces, and hyphens." > Also I use email_only in my mv_form_profile but it lets spaces in the > email address go through. Where is email_only defined or is there a > better definition to use? Space is actually a legal character in the local part of an email address as long as it's quoted and while I would recommend that you never create an email address with a space (or other funny characters) in it, you should accept one to avoid rejecting legitimate addresses. That said... email_only is defined in code/OrderCheck along with most of the profile checks. You can grab the regex from in there, modify it slightly and use it in a regex check instead. The space is octal 040, so you would do the following to exclude space from the regex: email=regex "^[\041-\077\101-\176]+\@[-A-Za-z0-9.]+\.[A-Za-z]+$/" "not an email address" Peter From peter at pajamian.dhs.org Thu Mar 12 20:30:03 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 13 Mar 2015 09:30:03 +1300 Subject: [ic] Quoting Identifiers Message-ID: <5501F74B.7090807@pajamian.dhs.org> At present Interchange doesn't quote identifiers when making SQL queries. This just caused an issue for a client of mine who is moving catalogs from an old version of mysql to a newer one and has a column name of "condition" which is now a reserved word in mysql (it didn't used to be). There are also a number of other good reasons to quote identifiers which I won't enumerate here. I would just push a patch up for this, except that this does result in a BC change. When you quote an identifier it becomes case-sensitive, but unquoted identifiers are not, or (as is the case in postgresql) are converted to lowercase. Therefore I think it's best to enable it with a config directive which can be added to the default catalog.cfg so new catalogs pick up the change, but old ones will need it to be explicitly enabled if this is desired. Thoughts? Peter From jon at endpoint.com Thu Mar 12 20:40:20 2015 From: jon at endpoint.com (Jon Jensen) Date: Thu, 12 Mar 2015 14:40:20 -0600 (MDT) Subject: [ic] Quoting Identifiers In-Reply-To: <5501F74B.7090807@pajamian.dhs.org> References: <5501F74B.7090807@pajamian.dhs.org> Message-ID: On Fri, 13 Mar 2015, Peter wrote: > At present Interchange doesn't quote identifiers when making SQL > queries. This just caused an issue for a client of mine who is moving > catalogs from an old version of mysql to a newer one and has a column > name of "condition" which is now a reserved word in mysql (it didn't > used to be). There are also a number of other good reasons to quote > identifiers which I won't enumerate here. > > I would just push a patch up for this, except that this does result in a > BC change. When you quote an identifier it becomes case-sensitive, but > unquoted identifiers are not, or (as is the case in postgresql) are > converted to lowercase. Therefore I think it's best to enable it with a > config directive which can be added to the default catalog.cfg so new > catalogs pick up the change, but old ones will need it to be explicitly > enabled if this is desired. It makes sense to me to implement it as a new non-default option. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From peter at pajamian.dhs.org Fri Mar 13 03:09:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 13 Mar 2015 16:09:39 +1300 Subject: [ic] Redundant code in DBI.pm? Message-ID: <550254F3.7030406@pajamian.dhs.org> IRT this block of code in the create_sql function in DBI.pm: for (my $i = 0; $i < @$columns; $i++) { $cols[$i] = $$columns[$i]; #::logDebug("checking column '$cols[$i]'"); if(defined $key) { $keycol = $i if $cols[$i] eq $key; } if(defined $config->{COLUMN_DEF}->{$cols[$i]}) { $cols[$i] .= " " . $config->{COLUMN_DEF}->{$cols[$i]}; } else { $cols[$i] .= " $def_type"; } $$columns[$i] = $cols[$i]; $$columns[$i] =~ s/\s+.*//; } The last two lines of the loop look to be redundant to me. $$columns[$i] already contains the column name, and $cols[$i] contain the column definition which is the column name, followed by a space and other stuff, so the last two names write $cols[$i] back to $$columns[$i] then strip the space + other stuff off the end leaving just the column name ... which is what was in $$columns[$i] to begin with? Can we scrap those two lines or is there something I'm missing? Peter From jon at endpoint.com Fri Mar 13 03:27:57 2015 From: jon at endpoint.com (Jon Jensen) Date: Thu, 12 Mar 2015 21:27:57 -0600 (MDT) Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <550254F3.7030406@pajamian.dhs.org> References: <550254F3.7030406@pajamian.dhs.org> Message-ID: On Fri, 13 Mar 2015, Peter wrote: > IRT this block of code in the create_sql function in DBI.pm: > > for (my $i = 0; $i < @$columns; $i++) { > $cols[$i] = $$columns[$i]; > #::logDebug("checking column '$cols[$i]'"); > if(defined $key) { > $keycol = $i if $cols[$i] eq $key; > } > if(defined $config->{COLUMN_DEF}->{$cols[$i]}) { > $cols[$i] .= " " . > $config->{COLUMN_DEF}->{$cols[$i]}; > } > else { > $cols[$i] .= " $def_type"; > } > $$columns[$i] = $cols[$i]; > $$columns[$i] =~ s/\s+.*//; > } > > The last two lines of the loop look to be redundant to me. > $$columns[$i] already contains the column name, and $cols[$i] contain > the column definition which is the column name, followed by a space and > other stuff, so the last two names write $cols[$i] back to $$columns[$i] > then strip the space + other stuff off the end leaving just the column > name ... which is what was in $$columns[$i] to begin with? > > Can we scrap those two lines or is there something I'm missing? I read it that way too. However, to avoid getting caught by anything "tricky, tricky" I think you would want to put some heavy debugging in there before & after and test pretty extensively. It would also be good to hear from Mike whether he remembers any obscure reason for this. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From peter at pajamian.dhs.org Fri Mar 13 03:40:56 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 13 Mar 2015 16:40:56 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: References: <550254F3.7030406@pajamian.dhs.org> Message-ID: <55025C48.2030500@pajamian.dhs.org> On 03/13/2015 04:27 PM, Jon Jensen wrote: > I read it that way too. > > However, to avoid getting caught by anything "tricky, tricky" I think > you would want to put some heavy debugging in there before & after and > test pretty extensively. Well, I can only see it being of any use in some edge case that I can't fathom, so I'm not sure I can test for an edge case when I don't even know what that edge case is. > It would also be good to hear from Mike whether he remembers any obscure > reason for this. Yeah, I am hoping to hear from Mike on this. That code goes back to the initial CVS import of that file so there is a good chance even Mike can't remember why it's there. Peter From jon at endpoint.com Fri Mar 13 03:46:10 2015 From: jon at endpoint.com (Jon Jensen) Date: Thu, 12 Mar 2015 21:46:10 -0600 (MDT) Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <55025C48.2030500@pajamian.dhs.org> References: <550254F3.7030406@pajamian.dhs.org> <55025C48.2030500@pajamian.dhs.org> Message-ID: On Fri, 13 Mar 2015, Peter wrote: >> However, to avoid getting caught by anything "tricky, tricky" I think >> you would want to put some heavy debugging in there before & after and >> test pretty extensively. > > Well, I can only see it being of any use in some edge case that I can't > fathom, so I'm not sure I can test for an edge case when I don't even > know what that edge case is. I'm just saying that our code reading is nice, but you would gain valuable real experience if you have evidence logged that the exact same values come out of there with and without those 2 lines you delete, for all the different database connections you can test. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From peter at pajamian.dhs.org Fri Mar 13 04:53:18 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 13 Mar 2015 17:53:18 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: References: <550254F3.7030406@pajamian.dhs.org> <55025C48.2030500@pajamian.dhs.org> Message-ID: <55026D3E.3020107@pajamian.dhs.org> On 03/13/2015 04:46 PM, Jon Jensen wrote: > I'm just saying that our code reading is nice, but you would gain > valuable real experience if you have evidence logged that the exact same > values come out of there with and without those 2 lines you delete, for > all the different database connections you can test. Fair enough, I'll do some sort of test on that before I push out any new code for this, then. I still want to hear from Mike, though. Peter From peter at pajamian.dhs.org Fri Mar 13 09:27:17 2015 From: peter at pajamian.dhs.org (Peter) Date: Fri, 13 Mar 2015 22:27:17 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <55026D3E.3020107@pajamian.dhs.org> References: <550254F3.7030406@pajamian.dhs.org> <55025C48.2030500@pajamian.dhs.org> <55026D3E.3020107@pajamian.dhs.org> Message-ID: <5502AD75.9000509@pajamian.dhs.org> On 03/13/2015 05:53 PM, Peter wrote: > On 03/13/2015 04:46 PM, Jon Jensen wrote: >> I'm just saying that our code reading is nice, but you would gain >> valuable real experience if you have evidence logged that the exact same >> values come out of there with and without those 2 lines you delete, for >> all the different database connections you can test. > > Fair enough, I'll do some sort of test on that before I push out any new > code for this, then. I did some debugging and the output looks exactly how we thought it would when reading the code. Peter From mikeh at perusion.com Fri Mar 13 12:07:20 2015 From: mikeh at perusion.com (Mike Heins) Date: Fri, 13 Mar 2015 08:07:20 -0400 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: References: <550254F3.7030406@pajamian.dhs.org> Message-ID: <20150313120720.GA27406@kim.perusion.com> Quoting Jon Jensen (jon at endpoint.com): > On Fri, 13 Mar 2015, Peter wrote: > > >IRT this block of code in the create_sql function in DBI.pm: > > > > for (my $i = 0; $i < @$columns; $i++) { > > $cols[$i] = $$columns[$i]; > >#::logDebug("checking column '$cols[$i]'"); > > if(defined $key) { > > $keycol = $i if $cols[$i] eq $key; > > } > > if(defined $config->{COLUMN_DEF}->{$cols[$i]}) { > > $cols[$i] .= " " . > >$config->{COLUMN_DEF}->{$cols[$i]}; > > } > > else { > > $cols[$i] .= " $def_type"; > > } > > $$columns[$i] = $cols[$i]; > > $$columns[$i] =~ s/\s+.*//; > > } > > > >The last two lines of the loop look to be redundant to me. > >$$columns[$i] already contains the column name, and $cols[$i] contain > >the column definition which is the column name, followed by a space and > >other stuff, so the last two names write $cols[$i] back to $$columns[$i] > >then strip the space + other stuff off the end leaving just the column > >name ... which is what was in $$columns[$i] to begin with? > > > >Can we scrap those two lines or is there something I'm missing? > > I read it that way too. > > However, to avoid getting caught by anything "tricky, tricky" I > think you would want to put some heavy debugging in there before & > after and test pretty extensively. > > It would also be good to hear from Mike whether he remembers any > obscure reason for this. The reason is that at you can define the type in the column label of the table, i.e. code price decimal(12) description varchar(200) image I don't think anyone has really ever used that, so it could go away if we want it to. -- Mike Heins Perusion -- Expert Interchange Consulting http://www.perusion.com/ phone +1.765.253.4194 Socialism -- ideas so good they have to be enforced at gunpoint. -- unknown From mikeh at perusion.com Fri Mar 13 12:58:45 2015 From: mikeh at perusion.com (Mike Heins) Date: Fri, 13 Mar 2015 08:58:45 -0400 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <20150313120720.GA27406@kim.perusion.com> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> Message-ID: <20150313125845.GA22843@kim.perusion.com> Quoting Mike Heins (mikeh at perusion.com): > Quoting Jon Jensen (jon at endpoint.com): > > On Fri, 13 Mar 2015, Peter wrote: > > > > >IRT this block of code in the create_sql function in DBI.pm: > > > > > > for (my $i = 0; $i < @$columns; $i++) { > > > $cols[$i] = $$columns[$i]; > > >#::logDebug("checking column '$cols[$i]'"); > > > if(defined $key) { > > > $keycol = $i if $cols[$i] eq $key; > > > } > > > if(defined $config->{COLUMN_DEF}->{$cols[$i]}) { > > > $cols[$i] .= " " . > > >$config->{COLUMN_DEF}->{$cols[$i]}; > > > } > > > else { > > > $cols[$i] .= " $def_type"; > > > } > > > $$columns[$i] = $cols[$i]; > > > $$columns[$i] =~ s/\s+.*//; > > > } > > > > > >The last two lines of the loop look to be redundant to me. > > >$$columns[$i] already contains the column name, and $cols[$i] contain > > >the column definition which is the column name, followed by a space and > > >other stuff, so the last two names write $cols[$i] back to $$columns[$i] > > >then strip the space + other stuff off the end leaving just the column > > >name ... which is what was in $$columns[$i] to begin with? > > > > > >Can we scrap those two lines or is there something I'm missing? > > > > I read it that way too. > > > > However, to avoid getting caught by anything "tricky, tricky" I > > think you would want to put some heavy debugging in there before & > > after and test pretty extensively. > > > > It would also be good to hear from Mike whether he remembers any > > obscure reason for this. > > The reason is that at you can define the type in the column > label of the table, i.e. > > code price decimal(12) description varchar(200) image > > I don't think anyone has really ever used that, so it could > go away if we want it to. Just tested that out of curiosity: catalog.cfg: Database foo foo.txt __SQLDSN__ In foo.txt: code varchar(33) description varchar(233) price decimal(12) 1111 The inimitable product. 11.11 Yields: mysql> desc foo; +-------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+---------------+------+-----+---------+-------+ | code | varchar(33) | YES | MUL | NULL | | | description | varchar(233) | YES | | NULL | | | price | decimal(12,0) | YES | | NULL | | +-------------+---------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) I see no reason to disturb it at this point. While I don't expect anyone uses it, I did for some old things, and I am constantly amazed at the old catalogs that are still out there. -- Mike Heins Perusion -- Expert Interchange Consulting http://www.perusion.com/ phone +1.765.253.4194 The sun, with all those planets revolving around it and dependent on it, can still ripen a bunch of grapes as if it had nothing else in the universe to do. -- Galileo From peter at pajamian.dhs.org Fri Mar 13 13:33:15 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 02:33:15 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <20150313125845.GA22843@kim.perusion.com> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> Message-ID: <5502E71B.1030002@pajamian.dhs.org> On 03/14/2015 01:58 AM, Mike Heins wrote: >>>> for (my $i = 0; $i < @$columns; $i++) { >>>> $cols[$i] = $$columns[$i]; >>>> #::logDebug("checking column '$cols[$i]'"); >>>> if(defined $key) { >>>> $keycol = $i if $cols[$i] eq $key; >>>> } >>>> if(defined $config->{COLUMN_DEF}->{$cols[$i]}) { >>>> $cols[$i] .= " " . >>>> $config->{COLUMN_DEF}->{$cols[$i]}; >>>> } >>>> else { >>>> $cols[$i] .= " $def_type"; >>>> } >>>> $$columns[$i] = $cols[$i]; >>>> $$columns[$i] =~ s/\s+.*//; >>>> } >> >> The reason is that at you can define the type in the column >> label of the table, i.e. >> >> code price decimal(12) description varchar(200) image Oh, I see, it looks like the first of those two lines is still redundant, though. I think if we were to remove the $$columns[$i] = $cols[$i] line and leave the next one in then the code would still work, the column type could be defined in the column and just the name would be left in @$columns. > Just tested that out of curiosity: Just to satisfy my own curiosity, can you comment out the $$columns[$i] = $cols[$i]; line and see if your test still works? Peter From mikeh at perusion.com Fri Mar 13 13:57:39 2015 From: mikeh at perusion.com (Mike Heins) Date: Fri, 13 Mar 2015 09:57:39 -0400 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <5502E71B.1030002@pajamian.dhs.org> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> Message-ID: <20150313135739.GA26932@kim.perusion.com> Quoting Peter (peter at pajamian.dhs.org): > On 03/14/2015 01:58 AM, Mike Heins wrote: > >>>> for (my $i = 0; $i < @$columns; $i++) { > >>>> $cols[$i] = $$columns[$i]; > >>>> #::logDebug("checking column '$cols[$i]'"); > >>>> if(defined $key) { > >>>> $keycol = $i if $cols[$i] eq $key; > >>>> } > >>>> if(defined $config->{COLUMN_DEF}->{$cols[$i]}) { > >>>> $cols[$i] .= " " . > >>>> $config->{COLUMN_DEF}->{$cols[$i]}; > >>>> } > >>>> else { > >>>> $cols[$i] .= " $def_type"; > >>>> } > >>>> $$columns[$i] = $cols[$i]; > >>>> $$columns[$i] =~ s/\s+.*//; > >>>> } > >> > >> The reason is that at you can define the type in the column > >> label of the table, i.e. > >> > >> code price decimal(12) description varchar(200) image > > Oh, I see, it looks like the first of those two lines is still > redundant, though. No, I don't think so. > I think if we were to remove the $$columns[$i] = > $cols[$i] line and leave the next one in then the code would still work, > the column type could be defined in the column and just the name would > be left in @$columns. > > > Just tested that out of curiosity: > > Just to satisfy my own curiosity, can you comment out the $$columns[$i] > = $cols[$i]; line and see if your test still works? > It seems to, and it seems safe and logical. But I would hesitate to modify it at this point unless you are going to remove the bug/feature completely. I would be for removing it if we did some sanity checks on the final product, i.e. check $$columns[i] for some field-name-like value. -- Mike Heins Perusion -- Expert Interchange Consulting http://www.perusion.com/ phone +1.765.253.4194 Life isn't fair, but it's good. -- Regina Brett From peter at pajamian.dhs.org Fri Mar 13 14:51:53 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 03:51:53 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <20150313135739.GA26932@kim.perusion.com> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> <20150313135739.GA26932@kim.perusion.com> Message-ID: <5502F989.4000108@pajamian.dhs.org> On 03/14/2015 02:57 AM, Mike Heins wrote: > It seems to, and it seems safe and logical. But I would hesitate to > modify it at this point unless you are going to remove the bug/feature > completely. I'm adding a feature: Database foo QUOTE_IDENTIFIERS ...or more likely: DatabaseDefault QUOTE_IDENTIFIERS See the ml thread "Quoting Identifiers" for more details. > I would be for removing it if we did some sanity checks on the final > product, i.e. check $$columns[i] for some field-name-like value. Well I've managed to write my code so that those two lines aren't affected by it whether QUOTE_IDENTIFIERS is set or not, so I can leave it in. I just noticed those lines when I was digging around in that section of code and I think the first can, at least, be removed without consequence. But I can leave it in to be extra safe. Peter From peter at pajamian.dhs.org Fri Mar 13 14:59:59 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 03:59:59 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <5502F989.4000108@pajamian.dhs.org> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> <20150313135739.GA26932@kim.perusion.com> <5502F989.4000108@pajamian.dhs.org> Message-ID: <5502FB6F.3090904@pajamian.dhs.org> On 03/14/2015 03:51 AM, Peter wrote: > Well I've managed to write my code so that those two lines aren't > affected by it whether QUOTE_IDENTIFIERS is set or not, so I can leave > it in. I just noticed those lines when I was digging around in that > section of code and I think the first can, at least, be removed without > consequence. But I can leave it in to be extra safe. Oh, sorry, I take it back. I can't leave that line in. The reason is as follows: When QUOTE_IDENTIFIERS is enabled, $columns will contain the unquoted column names as it did before, but @cols will contain the quoted column names that will be passed to the SQL db. so if the column name is copied from @cols to $columns it will break later code that needs the unquoted name (not destined for an SQL query). As I said earlier, and I believe you have confirmed in your tests, removing the first of those two lines does not break the feature you implemented with them, and the second regexp line still supports it. Peter From mikeh at perusion.com Fri Mar 13 15:23:09 2015 From: mikeh at perusion.com (Mike Heins) Date: Fri, 13 Mar 2015 11:23:09 -0400 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <5502FB6F.3090904@pajamian.dhs.org> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> <20150313135739.GA26932@kim.perusion.com> <5502F989.4000108@pajamian.dhs.org> <5502FB6F.3090904@pajamian.dhs.org> Message-ID: <20150313152309.GA30707@kim.perusion.com> Quoting Peter (peter at pajamian.dhs.org): > On 03/14/2015 03:51 AM, Peter wrote: > > Well I've managed to write my code so that those two lines aren't > > affected by it whether QUOTE_IDENTIFIERS is set or not, so I can leave > > it in. I just noticed those lines when I was digging around in that > > section of code and I think the first can, at least, be removed without > > consequence. But I can leave it in to be extra safe. > > Oh, sorry, I take it back. I can't leave that line in. The reason is > as follows: > > When QUOTE_IDENTIFIERS is enabled, $columns will contain the unquoted > column names as it did before, but @cols will contain the quoted column > names that will be passed to the SQL db. so if the column name is > copied from @cols to $columns it will break later code that needs the > unquoted name (not destined for an SQL query). > > As I said earlier, and I believe you have confirmed in your tests, > removing the first of those two lines does not break the feature you > implemented with them, and the second regexp line still supports it. OK. If anyone wonders why I bothered with any of this, at one point I was working on a database configuration system for Minivend 4. Spaces in field names were not on my radar (even if they were supported in SQL, which I don't think they were at that time), so it seemed like an easy way to specify a field name and definition as in SQL. This never was really used, as Akopia took over custody and we went in a different direction. -- Mike Heins Perusion -- Expert Interchange Consulting http://www.perusion.com/ phone +1.765.253.4194 There's nothing sweeter than life nor more precious than time. -- Barney From peter at pajamian.dhs.org Fri Mar 13 20:16:13 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 09:16:13 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <20150313152309.GA30707@kim.perusion.com> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> <20150313135739.GA26932@kim.perusion.com> <5502F989.4000108@pajamian.dhs.org> <5502FB6F.3090904@pajamian.dhs.org> <20150313152309.GA30707@kim.perusion.com> Message-ID: <5503458D.4090006@pajamian.dhs.org> On 03/14/2015 04:23 AM, Mike Heins wrote: > If anyone wonders why I bothered with any of this, at one point I > was working on a database configuration system for Minivend 4. Spaces > in field names were not on my radar (even if they were supported in > SQL, which I don't think they were at that time), so it seemed like an > easy way to specify a field name and definition as in SQL. This never > was really used, as Akopia took over custody and we went in a different > direction. So that's the other thing to consider. If we rip this out entirely we gain support for spaces in identifiers (especially with the addition of QUOTE_IDENTIFIERS). As it is now, space in an identifier will still bork with that section of code. We might possibly keep support for both with a lookbehind assertion that checks for the closing quote (that matches the opening quote) followed by space instead of just space. Peter From peter at pajamian.dhs.org Fri Mar 13 20:16:13 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 09:16:13 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <20150313152309.GA30707@kim.perusion.com> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> <20150313135739.GA26932@kim.perusion.com> <5502F989.4000108@pajamian.dhs.org> <5502FB6F.3090904@pajamian.dhs.org> <20150313152309.GA30707@kim.perusion.com> Message-ID: <5503458D.4090006@pajamian.dhs.org> On 03/14/2015 04:23 AM, Mike Heins wrote: > If anyone wonders why I bothered with any of this, at one point I > was working on a database configuration system for Minivend 4. Spaces > in field names were not on my radar (even if they were supported in > SQL, which I don't think they were at that time), so it seemed like an > easy way to specify a field name and definition as in SQL. This never > was really used, as Akopia took over custody and we went in a different > direction. So that's the other thing to consider. If we rip this out entirely we gain support for spaces in identifiers (especially with the addition of QUOTE_IDENTIFIERS). As it is now, space in an identifier will still bork with that section of code. We might possibly keep support for both with a lookbehind assertion that checks for the closing quote (that matches the opening quote) followed by space instead of just space. Peter From peter at pajamian.dhs.org Fri Mar 13 20:16:13 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 09:16:13 +1300 Subject: [ic] Redundant code in DBI.pm? In-Reply-To: <20150313152309.GA30707@kim.perusion.com> References: <550254F3.7030406@pajamian.dhs.org> <20150313120720.GA27406@kim.perusion.com> <20150313125845.GA22843@kim.perusion.com> <5502E71B.1030002@pajamian.dhs.org> <20150313135739.GA26932@kim.perusion.com> <5502F989.4000108@pajamian.dhs.org> <5502FB6F.3090904@pajamian.dhs.org> <20150313152309.GA30707@kim.perusion.com> Message-ID: <5503458D.4090006@pajamian.dhs.org> On 03/14/2015 04:23 AM, Mike Heins wrote: > If anyone wonders why I bothered with any of this, at one point I > was working on a database configuration system for Minivend 4. Spaces > in field names were not on my radar (even if they were supported in > SQL, which I don't think they were at that time), so it seemed like an > easy way to specify a field name and definition as in SQL. This never > was really used, as Akopia took over custody and we went in a different > direction. So that's the other thing to consider. If we rip this out entirely we gain support for spaces in identifiers (especially with the addition of QUOTE_IDENTIFIERS). As it is now, space in an identifier will still bork with that section of code. We might possibly keep support for both with a lookbehind assertion that checks for the closing quote (that matches the opening quote) followed by space instead of just space. Peter From peter at pajamian.dhs.org Fri Mar 13 22:36:03 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 11:36:03 +1300 Subject: [ic] [interchange] Add support for automatic quoting of identifiers in DBI. In-Reply-To: References: Message-ID: <55036653.7040501@pajamian.dhs.org> On 03/14/2015 11:30 AM, Peter Ajamian wrote: > commit de7af78f372f83d082142882ea2fe48267e3efe0 > Author: Peter Ajamian > Date: Sat Mar 14 11:12:33 2015 +1300 > > Add support for automatic quoting of identifiers in DBI. This setting works and nicely resolves some name clash issues that arose for a client when he upgraded mysql. I would like to eventually enable this in catalog.cfg that comes stock with the standard demo as I think it's a good idea to quote all identifiers in generated SQL, it avoids all sorts of potential issues. This would mean that new catalogs would pick up the setting but old ones would have to have it explicitly enabled so it would not break BC. My testing has not shown any issues, but this patch touches a lot of code in DBI.pm, so it is very possible that I introduced a bug. Please anyone who cares to help me test this let me know if there are any issues. Peter From peter at pajamian.dhs.org Fri Mar 13 22:38:12 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 11:38:12 +1300 Subject: [ic] [interchange] Add support for automatic quoting of identifiers in DBI. In-Reply-To: References: Message-ID: <550366D4.4060401@pajamian.dhs.org> On 03/14/2015 11:30 AM, Peter Ajamian wrote: > commit de7af78f372f83d082142882ea2fe48267e3efe0 > Author: Peter Ajamian > Date: Sat Mar 14 11:12:33 2015 +1300 > > Add support for automatic quoting of identifiers in DBI. One thing I forgot to mention in the git log is that this also adds a quote_identifier() db method, which you can pass an identifier to and it will return that identifier to you quoted. Peter From jon at endpoint.com Fri Mar 13 22:52:56 2015 From: jon at endpoint.com (Jon Jensen) Date: Fri, 13 Mar 2015 16:52:56 -0600 (MDT) Subject: [ic] [interchange] Add support for automatic quoting of identifiers in DBI. In-Reply-To: <55036653.7040501@pajamian.dhs.org> References: <55036653.7040501@pajamian.dhs.org> Message-ID: On Sat, 14 Mar 2015, Peter wrote: > My testing has not shown any issues, but this patch touches a lot of > code in DBI.pm, so it is very possible that I introduced a bug. Which databases and versions did you test it against? > I would like to eventually enable this in catalog.cfg that comes stock > with the standard demo as I think it's a good idea to quote all > identifiers in generated SQL, it avoids all sorts of potential issues. It seems reasonable to do that right now. It's not like people are making new catalogs based on the standard demo all the time these days. Even if they were, any new catalog should be tested so if this broke anything it wouldn't be the end of the world. The main thing is that it's not the default for old catalogs when someone upgrades, which you covered. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From peter at pajamian.dhs.org Fri Mar 13 22:59:45 2015 From: peter at pajamian.dhs.org (Peter) Date: Sat, 14 Mar 2015 11:59:45 +1300 Subject: [ic] [interchange] Add support for automatic quoting of identifiers in DBI. In-Reply-To: References: <55036653.7040501@pajamian.dhs.org> Message-ID: <55036BE1.1000302@pajamian.dhs.org> On 03/14/2015 11:52 AM, Jon Jensen wrote: > > Which databases and versions did you test it against? MySQL 5.6.23 >> I would like to eventually enable this in catalog.cfg that comes stock >> with the standard demo as I think it's a good idea to quote all >> identifiers in generated SQL, it avoids all sorts of potential issues. > > It seems reasonable to do that right now. Ok, den. Peter From peter at pajamian.dhs.org Tue Mar 17 06:05:39 2015 From: peter at pajamian.dhs.org (Peter) Date: Tue, 17 Mar 2015 19:05:39 +1300 Subject: [ic] [interchange] Add set_source SpecialSub. In-Reply-To: References: Message-ID: <5507C433.7060706@pajamian.dhs.org> On 03/17/2015 06:59 PM, Peter Ajamian wrote: > commit 5f1acc784e2247bb43c64e7ceff1154a04f5b31b > Author: Peter Ajamian > Date: Tue Mar 17 18:42:46 2015 +1300 > > Add set_source SpecialSub. This is basically code to fill a client need who found that they were getting a lot of search engine traffic with affiliate links. There are certainly ways of dealing with this in apache, as well as webmaster tools in the search engines themselves that can solve this, but this specialsub seemed to be an ideal solution that carries possible other features for interchange as well. Peter From jon at endpoint.com Tue Mar 17 14:49:11 2015 From: jon at endpoint.com (Jon Jensen) Date: Tue, 17 Mar 2015 08:49:11 -0600 (MDT) Subject: [ic] [interchange] Add set_source SpecialSub. In-Reply-To: <5507C433.7060706@pajamian.dhs.org> References: <5507C433.7060706@pajamian.dhs.org> Message-ID: On Tue, 17 Mar 2015, Peter wrote: >> Add set_source SpecialSub. > > This is basically code to fill a client need who found that they were > getting a lot of search engine traffic with affiliate links. There are > certainly ways of dealing with this in apache, as well as webmaster > tools in the search engines themselves that can solve this, but this > specialsub seemed to be an ideal solution that carries possible other > features for interchange as well. Thanks, Peter. That sounds useful! Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From adqtbiaoe at arnet.com.ar Mon Mar 23 10:02:11 2015 From: adqtbiaoe at arnet.com.ar (Perfumes Todas Las Marcas Y Los Mas Vendidos) Date: 23 Mar 2015 11:02:11 +0100 Subject: [ic] Mitad De Precio Envio Sin Cargo Mira Todas Las Primera Marcas interchange-users Message-ID: <20150323110211.B5D755B329145E66@arnet.com.ar> Perfumes Importados de primeras marcas y al precio mas bajo del mercado !! Las fragancias mas vendidas todas juntas y con stock permanente. Hace tu pedido y recibilo en la puerta de tu casa con ENVIO G-R-A-T-I-S !! Si, leiste bien, -envio SIN CARGO- a cualquier parte del pa?s (Argentina) ######################################################## # Givenchy / Dolce Gabbana / Lancome / Paco Rabanne / Calvin Klein # # Issey Miyake / Hugo Boss / Dior / Versace / Nina Ricci / Kenzo # # Carolina Herrera / Giorgio Armani / Lacoste / Y MUCHOS MAS !! # ######################################################## (( Precio PROMOCIONAL POR MUY POCOS DIAS )) PROMO# 1: 1 FRAGANCIA A ELECCI?N = $ 499 Finales (ENVIO INCLUIDO) ContraRembolso (Paga Al Recibir Por Correo Argentino En La Puerta De Su Casa Los $499) PROMO# 2: 2 FRAGANCIAS A ELECCI?N = $ 850 Finales (ENVIO INCLUIDO) ContraRembolso (Paga Al Recibir Por Correo Argentino En La Puerta De Su Casa Los $850) PROMO# 3: 3 FRAGANCIAS A ELECCI?N = $ 1.100 Finales (ENVIO INCLUIDO) ContraRembolso (Paga Al Recibir Por Correo Argentino En La Puerta De Su Casa Los $1.100) Fragancias para ellas: ---------------------- LANCOME "LA VIE EST BELLE" PACO RABANNE "LADY MILLION EAU MY GOLD!" DOLCE GABBANA "LIGHT BLUE" CAROLINA HERRERA "212 SEXY" CHRISTIAN DIOR "J'ADORE" CAROLINA HERRERA "212 VIP ROS?" CAROLINA HERRERA "CH EDP SUBLIME" VERSACE "BRIGHT CRYSTAL" NINA RICCI "NINA" KENZO "FLOWER IN THE AIR" NINA RICCI "LA TENTACION DE NINA" GIORGIO ARMANI "SI" DOLCE & GABBANA "INTENSE" GIVENCHY "ANGE AU ETRANGE LE SECRET" (etc, etc.) Disponemos de un catalogo con mas de 300 fragancias para mujer. Fragancias para ellos: ---------------------- PACO RABANNE "1 MILLION" PACO RABANNE "INVICTUS" CAROLINA HERRERA "212 VIP MEN" ISSEY MIYAKE "L?EAU D?ISSEY POUR HOMME SPORT MINT" DIOR "HOMME SPORT" CAROLINA HERRERA "212 SEXY" (HOMBRE) ISSEY MIYAKE "L?EAU D?ISSEY POUR HOMME" HUGO BOSS "BOTTLED UNLIMITED" GIORGIO ARMANI "CODE ICE" HUGO BOSS "RED" (etc, etc.) Disponemos de un catalogo con mas de 180 fragancias para hombre. Para visitar la web, comprar y ver mas detalles ingresar a: w w w . p e d i r p e r f u m e s . c o m (si copias y pegas, no dejar espacio entre letras) Por cuestiones de seguridad pusimos la direccion de la web con espacios entre las letras. From db at m-and-d.com Mon Mar 23 16:39:46 2015 From: db at m-and-d.com (DB) Date: Mon, 23 Mar 2015 12:39:46 -0400 Subject: [ic] OS suggestions for new server Message-ID: <551041D2.9060706@M-and-D.com> Currently my production IC5 runs on a Centos5 server. Although it's still supported for quite some time with security patches, I think it's time to move to a more modern OS. Just asking "what should I use" is a bit too general, so instead I'll ask for opinions of just two options: Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. DB From racke at linuxia.de Mon Mar 23 16:44:59 2015 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Mon, 23 Mar 2015 17:44:59 +0100 Subject: [ic] OS suggestions for new server In-Reply-To: <551041D2.9060706@M-and-D.com> References: <551041D2.9060706@M-and-D.com> Message-ID: <5510430B.9030407@linuxia.de> On 03/23/2015 05:39 PM, DB wrote: > Currently my production IC5 runs on a Centos5 server. Although it's > still supported for quite some time with security patches, I think it's > time to move to a more modern OS. Just asking "what should I use" is a > bit too general, so instead I'll ask for opinions of just two options: > Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. > Debian Jessie - no frills, excellent Perl support :-). Ubuntu doesn't have any added value for a server IMHO. Regards Racke -- Modern Perl, Dancer and eCommerce consulting. From jon at endpoint.com Mon Mar 23 16:52:36 2015 From: jon at endpoint.com (Jon Jensen) Date: Mon, 23 Mar 2015 12:52:36 -0400 (EDT) Subject: [ic] OS suggestions for new server In-Reply-To: <551041D2.9060706@M-and-D.com> References: <551041D2.9060706@M-and-D.com> Message-ID: On Mon, 23 Mar 2015, DB wrote: > Currently my production IC5 runs on a Centos5 server. Although it's > still supported for quite some time with security patches, I think it's > time to move to a more modern OS. Just asking "what should I use" is a > bit too general, so instead I'll ask for opinions of just two options: > Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. We use CentOS 7, Ubuntu 14.04, and Debian 7. They're all good OSes. We lean towards CentOS 7 for Perl and Interchange stuff in particular, but we will probably build our own RPMs based on Perl 5.20, since CentOS 7 comes with 5.16.3. So far we have used plenv for builds from source. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From peter at pajamian.dhs.org Mon Mar 23 20:28:13 2015 From: peter at pajamian.dhs.org (Peter) Date: Tue, 24 Mar 2015 09:28:13 +1300 Subject: [ic] OS suggestions for new server In-Reply-To: <551041D2.9060706@M-and-D.com> References: <551041D2.9060706@M-and-D.com> Message-ID: <5510775D.9010808@pajamian.dhs.org> On 03/24/2015 05:39 AM, DB wrote: > Currently my production IC5 runs on a Centos5 server. Although it's > still supported for quite some time with security patches, I think it's > time to move to a more modern OS. Just asking "what should I use" is a > bit too general, so instead I'll ask for opinions of just two options: > Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. Go with what you're used to, stick to CentOS. Build your own perl, I have even just recently seen issues with stock threaded perl and DBI with Interchange in RPC mode (in CentOS 6) and building an unthreaded perl solved it. Peter From db at m-and-d.com Mon Mar 23 22:17:27 2015 From: db at m-and-d.com (DB) Date: Mon, 23 Mar 2015 18:17:27 -0400 Subject: [ic] OS suggestions for new server In-Reply-To: <5510775D.9010808@pajamian.dhs.org> References: <5510775D.9010808@pajamian.dhs.org> Message-ID: <551090F7.80300@M-and-D.com> >> Currently my production IC5 runs on a Centos5 server. Although it's >> still supported for quite some time with security patches, I think it's >> time to move to a more modern OS. Just asking "what should I use" is a >> bit too general, so instead I'll ask for opinions of just two options: >> Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. > > Go with what you're used to, stick to CentOS. > > Build your own perl, I have even just recently seen issues with stock > threaded perl and DBI with Interchange in RPC mode (in CentOS 6) and > building an unthreaded perl solved it. > Thanks for the reply. I've done the custom perl thing before and would rather avoid it if possible. Sticking to the OS-supplied packages makes applying security patches relatively painless. Does anyone know if Ubuntu/Debian's perl is threaded? I'm using the stock perl on my Centos5 machine and it seems to be ok. Dave From josh at perusion.com Mon Mar 23 22:35:34 2015 From: josh at perusion.com (Josh Lavin) Date: Mon, 23 Mar 2015 15:35:34 -0700 Subject: [ic] OS suggestions for new server In-Reply-To: <5510775D.9010808@pajamian.dhs.org> References: <551041D2.9060706@M-and-D.com> <5510775D.9010808@pajamian.dhs.org> Message-ID: <20150323223534.GX1379@kate.perusion.com> Quoting Peter (peter at pajamian.dhs.org): > On 03/24/2015 05:39 AM, DB wrote: > > Currently my production IC5 runs on a Centos5 server. Although it's > > still supported for quite some time with security patches, I think it's > > time to move to a more modern OS. Just asking "what should I use" is a > > bit too general, so instead I'll ask for opinions of just two options: > > Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. > > Go with what you're used to, stick to CentOS. Get ready to learn systemd... -- Josh Lavin Perusion -- Expert Interchange Consulting http://www.perusion.com/ ... ask me about job opportunities ... From jon at endpoint.com Mon Mar 23 22:39:35 2015 From: jon at endpoint.com (Jon Jensen) Date: Mon, 23 Mar 2015 18:39:35 -0400 (EDT) Subject: [ic] OS suggestions for new server In-Reply-To: <20150323223534.GX1379@kate.perusion.com> References: <551041D2.9060706@M-and-D.com> <5510775D.9010808@pajamian.dhs.org> <20150323223534.GX1379@kate.perusion.com> Message-ID: On Mon, 23 Mar 2015, Josh Lavin wrote: >> Go with what you're used to, stick to CentOS. > > Get ready to learn systemd... Yes, no matter which major distro you pick. CentOS just got it earlier. :) Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From bob at bobcatos.com Mon Mar 23 22:43:26 2015 From: bob at bobcatos.com (Bob McClure Jr) Date: Mon, 23 Mar 2015 17:43:26 -0500 Subject: [ic] OS suggestions for new server In-Reply-To: <20150323223534.GX1379@kate.perusion.com> References: <551041D2.9060706@M-and-D.com> <5510775D.9010808@pajamian.dhs.org> <20150323223534.GX1379@kate.perusion.com> Message-ID: <20150323224326.GA8318@bobcat.bobcatos.com> On Mon, Mar 23, 2015 at 03:35:34PM -0700, Josh Lavin wrote: > Quoting Peter (peter at pajamian.dhs.org): > > On 03/24/2015 05:39 AM, DB wrote: > > > Currently my production IC5 runs on a Centos5 server. Although it's > > > still supported for quite some time with security patches, I think it's > > > time to move to a more modern OS. Just asking "what should I use" is a > > > bit too general, so instead I'll ask for opinions of just two options: > > > Centos 7 and Ubuntu 14.04. Any thoughts are appreciated. > > > > Go with what you're used to, stick to CentOS. > > Get ready to learn systemd... > > -- > Josh Lavin > Perusion -- Expert Interchange Consulting http://www.perusion.com/ > ... ask me about job opportunities ... ... and firewalld. One of my clients decided he wanted to upgrade from CentOS 5 to CentOS 7. We had to fight too much new stuff, and decided to fall back and do a more gentle upgrade to CentOS 6. N.B. - we haven't done the latter yet. Cheers, -- Bob McClure, Jr. Bobcat Open Systems, Inc. bob at bobcatos.com http://www.bobcatos.com We know that we live in him and he in us, because he has given us of his Spirit. 1 John 4:13 (NIV) From peter at pajamian.dhs.org Mon Mar 23 22:55:05 2015 From: peter at pajamian.dhs.org (Peter) Date: Tue, 24 Mar 2015 11:55:05 +1300 Subject: [ic] OS suggestions for new server In-Reply-To: <20150323224326.GA8318@bobcat.bobcatos.com> References: <551041D2.9060706@M-and-D.com> <5510775D.9010808@pajamian.dhs.org> <20150323223534.GX1379@kate.perusion.com> <20150323224326.GA8318@bobcat.bobcatos.com> Message-ID: <551099C9.6040601@pajamian.dhs.org> On 03/24/2015 11:43 AM, Bob McClure Jr wrote: > On Mon, Mar 23, 2015 at 03:35:34PM -0700, Josh Lavin wrote: >> Get ready to learn systemd... No matter which distro you pick nowadays. > ... and firewalld. You can still use iptables in CentOS 7, it's trivial to disable firewalld. Same goes for NetworkManager (which I also recommend you disable and just stick with the older network scripts). Peter From jon at endpoint.com Mon Mar 23 22:56:15 2015 From: jon at endpoint.com (Jon Jensen) Date: Mon, 23 Mar 2015 18:56:15 -0400 (EDT) Subject: [ic] OS suggestions for new server In-Reply-To: <20150323224326.GA8318@bobcat.bobcatos.com> References: <551041D2.9060706@M-and-D.com> <5510775D.9010808@pajamian.dhs.org> <20150323223534.GX1379@kate.perusion.com> <20150323224326.GA8318@bobcat.bobcatos.com> Message-ID: On Mon, 23 Mar 2015, Bob McClure Jr wrote: >> Get ready to learn systemd... > > ... and firewalld. One of my clients decided he wanted to upgrade from > CentOS 5 to CentOS 7. We had to fight too much new stuff, and decided > to fall back and do a more gentle upgrade to CentOS 6. Nah, firewalld is an optional thing on RHEL 7 / CentOS 7. Just `yum remove firewalld && yum install iptables-services` and you'll have essentially the same thing earlier RHEL/CentOS versions had. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From peter at pajamian.dhs.org Mon Mar 23 23:00:35 2015 From: peter at pajamian.dhs.org (Peter) Date: Tue, 24 Mar 2015 12:00:35 +1300 Subject: [ic] OS suggestions for new server In-Reply-To: <20150323224326.GA8318@bobcat.bobcatos.com> References: <551041D2.9060706@M-and-D.com> <5510775D.9010808@pajamian.dhs.org> <20150323223534.GX1379@kate.perusion.com> <20150323224326.GA8318@bobcat.bobcatos.com> Message-ID: <55109B13.7030901@pajamian.dhs.org> On 03/24/2015 11:43 AM, Bob McClure Jr wrote: > One of my clients decided he wanted to upgrade from CentOS 5 to CentOS 7. Oh, and the old service and chkconfig commands still work in CentOS 7 as wrappers around the newer systemctl command so you really don't have to learn much new stuff. That said, I am definitely not a fan of systemd, but the pain of the switch can be largely mitigated. Peter From lyn at zolotek.net Tue Mar 24 13:17:44 2015 From: lyn at zolotek.net (Lyn St George) Date: Tue, 24 Mar 2015 13:17:44 +0000 Subject: [ic] OS suggestions for new server In-Reply-To: <551099C9.6040601@pajamian.dhs.org> References: <551041D2.9060706@M-and-D.com> <20150323224326.GA8318@bobcat.bobcatos.com> <551099C9.6040601@pajamian.dhs.org> Message-ID: <6075808.pjMJq3APjA@pip> On Tuesday 24 March 2015 11:55:05 Peter wrote: > On 03/24/2015 11:43 AM, Bob McClure Jr wrote: > > On Mon, Mar 23, 2015 at 03:35:34PM -0700, Josh Lavin wrote: > >> Get ready to learn systemd... > > No matter which distro you pick nowadays. > > > ... and firewalld. > > You can still use iptables in CentOS 7, it's trivial to disable > firewalld. Same goes for NetworkManager (which I also recommend you > disable and just stick with the older network scripts). > > > Peter While source-based distros like Gentoo are not everyone's preference, it's worth noting that disabling systemd is just a matter of adding "-systemd" to the global USE flags. And the choice between iptables and firewalld is yours, not the system's. Both systemd and that accursed akonadi in KDE are yet more evidence of the *nix world being invaded by aliens, IMO ... Lyn From MindNews at ninjaframework.com Tue Mar 24 21:43:44 2015 From: MindNews at ninjaframework.com (MindNews) Date: Tue, 24 Mar 2015 21:43:44 +0000 (UTC) Subject: [ic] Doctor reveals a secret to unlock the human mind... LIMITLESS possibilities! Message-ID: <20150324214444.52FC6202EE@ninjaframework.com> Ever wish there was something simple that can turn you into a you true genius? What if we told you, that it's totally possible. The world's richest people make use of a technique that unlocks the complete potential of their brainpower. [VIDEO] - http://tinyurl.com/Unlock-the-Power-of-ur-MIND New research reveals how the global elite make use of these methods in order to; * Help the brain grow "YOUNGER" with each passing day * Boost intelligence - actually raise IQ * Sharpen memory & restore powers of recall And SO much more... - http://tinyurl.com/Unlock-the-Power-of-ur-MIND Here's To Your New AMAZING Memory, Dr. S. Klaymoar ================================== If you no longer wish to recieve newsletters, please follow the instructions below: Remove yourself here: http://tinyurl.com/coggedout or write to: 302 Washington St. #150 San Diego, CA 92103 From sbatschelet at mac.com Wed Mar 25 12:15:29 2015 From: sbatschelet at mac.com (Sam Batschelet) Date: Wed, 25 Mar 2015 08:15:29 -0400 Subject: [ic] 2015 Conference Meeting Monday March 30th 11am EST #interchange Message-ID: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> Interchange Users, Join us on IRC (freenode) #interchange next Monday March 30th for a meeting regarding this years conference slated for Fall. Topics covered during the meeting will include venue selection and proposed dates. Your input and support is very important to the events success. See you then! Warm Regards, Sam Batschelet From bill at bottlenose-wine.com Wed Mar 25 13:51:34 2015 From: bill at bottlenose-wine.com (William Carr) Date: Wed, 25 Mar 2015 13:51:34 +0000 Subject: [ic] 2015 Conference Meeting Monday March 30th 11am EST #interchange In-Reply-To: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> References: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> Message-ID: <0000014c5133d837-3c8133e3-cb0f-4c54-bb71-1f4b61491f51-000000@email.amazonses.com> I?ll be there. Sam, so I may better prepare, what are our values? -Bill > On Mar 25, 2015, at 8:15 AM, Sam Batschelet wrote: > > Interchange Users, > Join us on IRC (freenode) #interchange next Monday March 30th for a meeting regarding this years conference slated for Fall. Topics covered during the meeting will include venue selection and proposed dates. Your input and support is very important to the events success. See you then! > > Warm Regards, > > Sam Batschelet > _______________________________________________ > interchange-users mailing list > interchange-users at icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users Bill Carr, President at Bottlenose (413) 584-0400 http://www.bottlenose-wine.com ?Download vCard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at endpoint.com Wed Mar 25 16:10:18 2015 From: jon at endpoint.com (Jon Jensen) Date: Wed, 25 Mar 2015 12:10:18 -0400 (EDT) Subject: [ic] 2015 Conference Meeting Monday March 30th 11am EST #interchange In-Reply-To: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> References: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> Message-ID: On Wed, 25 Mar 2015, Sam Batschelet wrote: > Join us on IRC (freenode) #interchange next Monday March 30th for a > meeting regarding this years conference slated for Fall. Topics covered > during the meeting will include venue selection and proposed dates. > Your input and support is very important to the events success. See you > then! Thanks, Sam. In the subject you say "11am EST", but EST = standard time = not daylight saving. But Eastern is in daylight saving time now, so I presume you mean EDT, right? Just want to make sure. :) Talk to you all then. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From bob at bobcatos.com Wed Mar 25 21:15:37 2015 From: bob at bobcatos.com (Bob McClure Jr) Date: Wed, 25 Mar 2015 16:15:37 -0500 Subject: [ic] Paypal with Interchange Message-ID: <20150325211537.GA15274@bobcat.bobcatos.com> I'm an interchange newbie and am trying to set up a cart for a client to use Paypal. I don't see anything in the docs about using Paypal, and a web search turns up http://interchange.rtfm.info/icdocs/payments/PaypalPro.html which describes the setup and mentions Vend::Payment::PaypalPro but no clues where to find it. CPAN doesn't have it. Then I found https://erikfantasia.wordpress.com/paypal/ but all links to downloading the module 404 out. What am I missing? Cheers, -- Bob McClure, Jr. Bobcat Open Systems, Inc. bob at bobcatos.com http://www.bobcatos.com Here is a trustworthy saying that deserves full acceptance: Christ Jesus came into the world to save sinners -- of whom I am the worst. 1 Timothy 1:15 (NIV) From jon at endpoint.com Wed Mar 25 21:21:45 2015 From: jon at endpoint.com (Jon Jensen) Date: Wed, 25 Mar 2015 17:21:45 -0400 (EDT) Subject: [ic] Paypal with Interchange In-Reply-To: <20150325211537.GA15274@bobcat.bobcatos.com> References: <20150325211537.GA15274@bobcat.bobcatos.com> Message-ID: On Wed, 25 Mar 2015, Bob McClure Jr wrote: > I'm an interchange newbie and am trying to set up a cart for a client to > use Paypal. I don't see anything in the docs about using Paypal, and a > web search turns up > > http://interchange.rtfm.info/icdocs/payments/PaypalPro.html > > which describes the setup and mentions Vend::Payment::PaypalPro but no > clues where to find it. CPAN doesn't have it. I believe what you want is already included with Interchange. It's Vend::Payment::PaypalExpress and is here: https://github.com/interchange/interchange/blob/master/lib/Vend/Payment/PaypalExpress.pm Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From racke at linuxia.de Thu Mar 26 07:54:59 2015 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Thu, 26 Mar 2015 08:54:59 +0100 Subject: [ic] 2015 Conference Meeting Monday March 30th 11am EST #interchange In-Reply-To: References: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> Message-ID: <5513BB53.10208@linuxia.de> On 03/25/2015 05:10 PM, Jon Jensen wrote: > On Wed, 25 Mar 2015, Sam Batschelet wrote: > >> Join us on IRC (freenode) #interchange next Monday March 30th for a meeting regarding this years conference slated for Fall. Topics covered during the meeting will include venue selection and proposed dates. Your input and support is very important to the events success. See you then! > > Thanks, Sam. > > In the subject you say "11am EST", but EST = standard time = not daylight saving. But Eastern is in daylight saving time now, so I presume you mean EDT, right? Just want to make sure. :) > > Talk to you all then. > > Jon > > Yes, EDT 11 am and 5 pm in most of Europe. Regards Racke -- Modern Perl, Dancer and eCommerce consulting. From bob at bobcatos.com Thu Mar 26 12:28:12 2015 From: bob at bobcatos.com (Bob McClure Jr) Date: Thu, 26 Mar 2015 07:28:12 -0500 Subject: [ic] Paypal with Interchange In-Reply-To: References: <20150325211537.GA15274@bobcat.bobcatos.com> Message-ID: <20150326122812.GB12684@bobcat.bobcatos.com> On Wed, Mar 25, 2015 at 05:21:45PM -0400, Jon Jensen wrote: > On Wed, 25 Mar 2015, Bob McClure Jr wrote: > > >I'm an interchange newbie and am trying to set up a cart for a > >client to use Paypal. I don't see anything in the docs about > >using Paypal, and a web search turns up > > > >http://interchange.rtfm.info/icdocs/payments/PaypalPro.html > > > >which describes the setup and mentions Vend::Payment::PaypalPro > >but no clues where to find it. CPAN doesn't have it. > > I believe what you want is already included with Interchange. It's > Vend::Payment::PaypalExpress and is here: > > https://github.com/interchange/interchange/blob/master/lib/Vend/Payment/PaypalExpress.pm And in the distribution. Excellent. Thank you for the clue. > Jon > > > -- > Jon Jensen > End Point Corporation > https://www.endpoint.com/ Cheers, -- Bob McClure, Jr. Bobcat Open Systems, Inc. bob at bobcatos.com http://www.bobcatos.com And now, dear children, continue in him, so that when he appears we may be confident and unashamed before him at his coming. 1 John 2:28 (NIV) From bob at bobcatos.com Fri Mar 27 19:36:07 2015 From: bob at bobcatos.com (Bob McClure Jr) Date: Fri, 27 Mar 2015 14:36:07 -0500 Subject: [ic] Need help with PaypalExpress.pm documentation Message-ID: <20150327193607.GA9649@bobcat.bobcatos.com> I've been through the Catalog Tutorial and set things up for testing. I will be processing only with PayPal Express. The documentation in PaypalExpress.pm is pretty grim. First, the "man" process renders the instructions pretty much unintelligible because it is allowed to wrap and reformat lines, so I just read the .pm file. At line 82, it starts with "To have Paypal co-operate with your normal payment service provider ...". I'm using Paypal only, so I can skip that part, but I'm unclear how far that part extends, so I don't know where to continue for my configuration. Any clues, please? Cheers, -- Bob McClure, Jr. Bobcat Open Systems, Inc. bob at bobcatos.com http://www.bobcatos.com "Because he loves me," says the LORD, "I will rescue him; I will protect him, for he acknowledges my name." Psalm 91:14 (NIV) From lyn at zolotek.net Fri Mar 27 20:02:36 2015 From: lyn at zolotek.net (Lyn St George) Date: Fri, 27 Mar 2015 20:02:36 +0000 Subject: [ic] Need help with PaypalExpress.pm documentation In-Reply-To: <20150327193607.GA9649@bobcat.bobcatos.com> References: <20150327193607.GA9649@bobcat.bobcatos.com> Message-ID: <2226209.2c0PGRBTM1@pip> On Friday 27 March 2015 14:36:07 Bob McClure Jr wrote: > I've been through the Catalog Tutorial and set things up for testing. > I will be processing only with PayPal Express. > > The documentation in PaypalExpress.pm is pretty grim. Hmm ... > First, the > "man" process renders the instructions pretty much unintelligible > because it is allowed to wrap and reformat lines, so I just read the > .pm file. > > At line 82, it starts with "To have Paypal co-operate with your normal > payment service provider ...". I'm using Paypal only, so I can skip > that part, but I'm unclear how far that part extends, so I don't know > where to continue for my configuration. > > Any clues, please? Line 167: "Of course, if PaypalExpress is to be your only payment method ... " From bob at bobcatos.com Fri Mar 27 20:50:03 2015 From: bob at bobcatos.com (Bob McClure Jr) Date: Fri, 27 Mar 2015 15:50:03 -0500 Subject: [ic] Need help with PaypalExpress.pm documentation In-Reply-To: <2226209.2c0PGRBTM1@pip> References: <20150327193607.GA9649@bobcat.bobcatos.com> <2226209.2c0PGRBTM1@pip> Message-ID: <20150327205003.GA15519@bobcat.bobcatos.com> Hi Lyn, On Fri, Mar 27, 2015 at 08:02:36PM +0000, Lyn St George wrote: > On Friday 27 March 2015 14:36:07 Bob McClure Jr wrote: > > I've been through the Catalog Tutorial and set things up for testing. > > I will be processing only with PayPal Express. > > > > The documentation in PaypalExpress.pm is pretty grim. > > Hmm ... > > > First, the > > "man" process renders the instructions pretty much unintelligible > > because it is allowed to wrap and reformat lines, so I just read the > > .pm file. > > > > At line 82, it starts with "To have Paypal co-operate with your normal > > payment service provider ...". I'm using Paypal only, so I can skip > > that part, but I'm unclear how far that part extends, so I don't know > > where to continue for my configuration. > > > > Any clues, please? > > Line 167: "Of course, if PaypalExpress is to be your only payment method ... " Thank you very much. Golly, I see how I missed it. Cheers, -- Bob McClure, Jr. Bobcat Open Systems, Inc. bob at bobcatos.com http://www.bobcatos.com "Because he loves me," says the LORD, "I will rescue him; I will protect him, for he acknowledges my name." Psalm 91:14 (NIV) From sbatschelet at mac.com Mon Mar 30 14:54:12 2015 From: sbatschelet at mac.com (Sam Batschelet) Date: Mon, 30 Mar 2015 10:54:12 -0400 Subject: [ic] 2015 Conference Meeting Monday March 30th 11am EST #interchange In-Reply-To: <5513BB53.10208@linuxia.de> References: <1C556861-AC6F-464B-98AA-9AA9128CAEFD@mac.com> <5513BB53.10208@linuxia.de> Message-ID: On Mar 26, 2015, at 3:54 AM, Stefan Hornburg (Racke) wrote: > On 03/25/2015 05:10 PM, Jon Jensen wrote: >> On Wed, 25 Mar 2015, Sam Batschelet wrote: >> >>> Join us on IRC (freenode) #interchange next Monday March 30th for a meeting regarding this years conference slated for Fall. Topics covered during the meeting will include venue selection and proposed dates. Your input and support is very important to the events success. See you then! >> >> Thanks, Sam. >> >> In the subject you say "11am EST", but EST = standard time = not daylight saving. But Eastern is in daylight saving time now, so I presume you mean EDT, right? Just want to make sure. :) >> >> Talk to you all then. >> >> Jon >> >> > > Yes, EDT 11 am and 5 pm in most of Europe. Last minute reminder meeting start in just a few minutes #interchange 11:00 EDT. Warm Regards, Sam Batschelet -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From racke at linuxia.de Tue Mar 31 14:10:54 2015 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Tue, 31 Mar 2015 16:10:54 +0200 Subject: [ic] Conference 2015 Message-ID: <551AAAEE.9060604@linuxia.de> Yesterday on the IRC meeting we came up with the following plan for this year's conference: Location We decided to change the location after two successful years at the Westbranch venue to the Vienna area in Austria. This makes it easier for European people to attend while we still get the main developers from the states. Visiting Vienna is definitely a highlight (rated best in travel by Lonely Planet [1]) while prices are reasonable and we can cut good hotel deals. Topic The conference title will stay "Perl::Dancer Conference", but we will focus on several related themes such as Ecommerce, mobile web + payment, Dancer and DBIx::Class. Please let us know what interests you most. Dates We plan for the week of 19th-23th October. Please let us know whether these dates fit in your schedule or not. Regards Racke [1] http://www.lonelyplanet.com/austria/vienna -- Modern Perl, Dancer and eCommerce consulting. From bill at bottlenose-wine.com Tue Mar 31 14:25:01 2015 From: bill at bottlenose-wine.com (William Carr) Date: Tue, 31 Mar 2015 14:25:01 +0000 Subject: [ic] Conference 2015 In-Reply-To: <551AAAEE.9060604@linuxia.de> References: <551AAAEE.9060604@linuxia.de> Message-ID: <0000014c7038a127-56689d9a-6ba2-418c-b6f7-44897dc3d5c3-000000@email.amazonses.com> Hi, Racke. I think you?ve nailed it right on. Evan and I will be in attendance. -Bill > On Mar 31, 2015, at 10:10 AM, Stefan Hornburg (Racke) wrote: > > Yesterday on the IRC meeting we came up with the following plan for this year's conference: > > Location > > We decided to change the location after two successful years at the Westbranch venue to the Vienna area in Austria. > This makes it easier for European people to attend while we still get the main developers from the states. > Visiting Vienna is definitely a highlight (rated best in travel by Lonely Planet [1]) while prices are reasonable and we can cut good hotel deals. > > Topic > > The conference title will stay "Perl::Dancer Conference", but we will focus on several related themes such as Ecommerce, mobile web + payment, > Dancer and DBIx::Class. Please let us know what interests you most. > > Dates > > We plan for the week of 19th-23th October. Please let us know whether these dates fit in your schedule or not. > > Regards > Racke > > [1] http://www.lonelyplanet.com/austria/vienna > > -- > Modern Perl, Dancer and eCommerce consulting. > > _______________________________________________ > interchange-users mailing list > interchange-users at icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users Bill Carr, President at Bottlenose (413) 584-0400 http://www.bottlenose-wine.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbatschelet at mac.com Tue Mar 31 14:37:05 2015 From: sbatschelet at mac.com (Sam Batschelet) Date: Tue, 31 Mar 2015 10:37:05 -0400 Subject: [ic] Conference 2015 In-Reply-To: <551AAAEE.9060604@linuxia.de> References: <551AAAEE.9060604@linuxia.de> Message-ID: On Mar 31, 2015, at 10:10 AM, Stefan Hornburg (Racke) wrote: > Yesterday on the IRC meeting we came up with the following plan for this year's conference: > > Location > > We decided to change the location after two successful years at the Westbranch venue to the Vienna area in Austria. > This makes it easier for European people to attend while we still get the main developers from the states. > Visiting Vienna is definitely a highlight (rated best in travel by Lonely Planet [1]) while prices are reasonable and we can cut good hotel deals. > > Topic > > The conference title will stay "Perl::Dancer Conference", but we will focus on several related themes such as Ecommerce, mobile web + payment, > Dancer and DBIx::Class. Please let us know what interests you most. > > Dates > > We plan for the week of 19th-23th October. Please let us know whether these dates fit in your schedule or not. Sounds great I plan on attending. -Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bob at nleaudio.com Tue Mar 31 16:00:12 2015 From: bob at nleaudio.com (Bob Puff) Date: Tue, 31 Mar 2015 12:00:12 -0400 Subject: [ic] Setting email sender address Message-ID: <20150331155400.M64290@nleaudio.com> I have a few different websites running IC on the same server. When someone enters an email address at checkout that is invalid, as the hostmaster, I see the bounce. I would like to have IC set the email envelope sender for each catalog, so that bounces go to the appropriate admin for their respective catalogs (instead of just going to root, or the interch user). From josh at perusion.com Tue Mar 31 16:42:59 2015 From: josh at perusion.com (Josh Lavin) Date: Tue, 31 Mar 2015 09:42:59 -0700 Subject: [ic] Setting email sender address In-Reply-To: <20150331155400.M64290@nleaudio.com> References: <20150331155400.M64290@nleaudio.com> Message-ID: <20150331164259.GG5913@kate.perusion.com> Quoting Bob Puff (bob at nleaudio.com): > I have a few different websites running IC on the same server. When someone > enters an email address at checkout that is invalid, as the hostmaster, I see > the bounce. I would like to have IC set the email envelope sender for each > catalog, so that bounces go to the appropriate admin for their respective > catalogs (instead of just going to root, or the interch user). When I use sendmail, I put the catalog owner in "trusted-users" (/etc/mail/trusted-users on CentOS), and then in catalog.cfg: SendMailProgram /usr/local/bin/sendmail_bg -f __EMAIL_INFO__ sendmail_bg is a script that just forks sendmail in the background. Here is mine: ---- #!/usr/bin/perl use File::Temp; my $basedir = "/tmp/sendmail-$ENV{'USER'}"; my $sendmail = '/usr/sbin/sendmail'; my @opts; for(@ARGV) { push @opts, $_; } for(@opts) { shift(@ARGV) } my $opt = join ' ', @opts; umask 2; mkdir $basedir unless -d $basedir; my $tmp = File::Temp->new( DIR => $basedir ); $tmp->unlink_on_destroy(0); my $tmpnam = $tmp->filename; open OUT, "> $tmpnam" or die "Cannot create $tmpnam: $!\n"; my $cmdline = join " ", $sendmail, $opt, '<', $tmpnam, '&'; while(<>) { print OUT $_; } close OUT; system($cmdline); if($?) { die "Failed to fork sendmail: $!\n" } -- Josh Lavin Perusion -- Expert Interchange Consulting http://www.perusion.com/ ... ask me about job opportunities ...