I need to install Zend Optimizer to get Whois.Cart to work.
Whois.Cart’s info says to get you guys to do it. Is that possible? Or are there instructions on how i could do this myself without screwing anything up with Interworx?
Install it yourself…
I use Whois.Cart too with my InterWorx CP powered server. I downloaded and installed Zend Optimizer from http://www.zend.com without any problems.
Steps to follow: (Assuming Fedora Core Linux, should work with other similar linux distros though.)
Please make sure you are logged in to the server as ‘root’.
- Download Zend Optimizer 2.5.7 from http://www.envisiont.net/ZendOptimizer-2.5.7-linux-glibc21-i386.tar.gz (My Server) or http://www.zend.com/store/free_download.php?pid=13 (Choose the version which says Linux glibc2.1)
# wget http://www.envisiont.net/ZendOptimizer-2.5.7-linux-glibc21-i386.tar.gz
- Untar the archive:
# tar -zxvf ZendOptimizer-2.5.7-linux-glibc21-i386.tar.gz
- Change to the Newly unarchived folder and follow these steps.
# cd ZendOptimizer-2.5.7-linux-glibc21-i386
# ./install.sh
The above will start the install process and ask you for some minimal user input, at the end of it you should have Zend Optimizer running with PHP+Apache on your Interworx Server without any issues.
Thanks for writing all that out =) I tried it myself when i saw no one had replied with a solution… just took a chance figuring a Linux admin friend of mine would fix it if i broke it =P It worked beautifully… just following the steps you listed.
I hope all that you wrote out helps someone else in a similar position sometime!
Thanks again =)
Whois.cart
Well after weeks of trying to get this to work on my system it still does not.
It allows orders to be placed but once the order is accepted by the admin panel in whois.cart, which requires the two “yes” buttons to be pressed twice before, which seems where the first error lies. It then sends the customer a email to say welcome to the system etc and adds the hosting account into interworx but no email is sent with the details of how to login to the interworx account, just the whois.cart side.
A long list of support tickets to and from whois.cart support and the issue is still not resolved.
So I would just like to get an idea from the people using interworx, how many of you run whois.cart?
Anyone else had these issues, if so please shed some light on this issue I am having because im at the end of the line with it.
Or maybe you just gave up and moved to another package? I have tried modernbill but this is fair to complex for my needs.
Running:
Fedora 3
Zend Engine v1.3.0
PHP 4.3.11.iworx
Hi Perry,
Unfortunately your system is manifesting errors which fall outside the scope of the cart. I can understand the aggravation, but the cart does depend on a healthy server environment to operate correctly. In your case, as discussed, when the cart triggers the XMLRPC command to create the plan on your Interworx machine, a segfault occurs:
Program received signal SIGTERM, Terminated. [Switching to Thread -1208826176 (LWP 25413)]
0x0039e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0 0x0039e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00c0da1d in ___newselect_nocancel () from /lib/tls/libc.so.6
#2 0x018e1f78 in php_sock_stream_wait_for_data (stream=0xfffffdfe, sock=0x996e79c) at /usr/src/redhat/BUILD/php-4.3.10/main/network.c:1032
#3 0x018e1ffd in php_sockop_read (stream=0x996e7cc, buf=0x99ed65c “”, count=8192) at /usr/src/redhat/BUILD/php-4.3.10/main/network.c:1075
#4 0x018dd63e in php_stream_fill_read_buffer (stream=0x996e7cc, size=0) at /usr/src/redhat/BUILD/php-4.3.10/main/streams.c:584
#5 0x018dd74a in _php_stream_read (stream=0x996e7cc, buf=0x99e5644 “”, size=32768) at /usr/src/redhat/BUILD/php-4.3.10/main/streams.c:632
#6 0x0188425c in zif_fread (ht=2, return_value=0x9950f1c, this_ptr=0x0, return_value_used=1) at /usr/src/redhat/BUILD/php-4.3.10/ext/standard/file.c:2190
#7 0x07e98bd2 in get_module () from /usr/local/Zend/lib/Optimizer-2.5.7/php-4.3.x/ZendOptimizer.so
#8 0x09950f1c in ?? ()
#9 0x00000000 in ?? ()
Where PHP is concerned, it shouldn’t be possible in any combination of commands to generate a segfault which is the 'code’s fault. PHP is a tier-neutral and architecture neutral application. When the above occurs, it’s that a component that PHP depends on, is failing - reason unknown thus far.
Note that in defense of Interworx, it’s likely that this isn’t even Interworx’s fault either, but that of the OS on which the machine is installed.
If you’ve received my last message, you’ll note that I’ve refunded your account out of good will. This will give you a chance to explore other applications at your consideration, and if so desired, to purchase whois.cart anew once you manage to sort out your operational problems with the server. This and the last “impossible” mysql error log indicate that there definitely exist more deeply-rooted problems than readily appears.
It could also be that extenal to PHP, that Zend Optimizer is to blame, it has caused stranger problems in the past - I’d suggest keeping an eye out for 2.5.10 which is apparently slated for imminent release. I wish you all the best, and hope that other Interworx/WhoisCart() users will chime in at your request to confirm that their systems work fine - I count 32 on our client list whose names of course I cannot release.
A long list of support tickets to and from whois.cart support and the issue is still not resolved.
The experience in the people who’ve attempted to help you solve this, since we do not directly provide support for OS components, is immense - and our intentions were constructive at every step. Kindly understand that given the root of the problem, that a “long list” of support tickets even occured, would be sign of our good intentions. In reality, one single ticket after we’d deducted the above stacktrace which identifies and unfortunately does not solve the problem, would have been sole due.
This said, good luck - and I hope that in the end, you’ll realize that the stacktrace above, and everything we’ve told you are true. I’m crossing my fingers for you personally, and hope to soon welcome you amongst our member community again.
Cordially.
Alexandre
Similar problems here =/ I run WhoisCart and I’ve had a long correspondance with the Saeven team about this. I personally didn’t even realize that Interworx was supposed to send out an email with the info.
What I tried to do instead was modify the default_receipt.htm file and add the info for Interworx. That’s where my correspondance started with them. I was looking for the variable for “domain name” and they told me about segfault errors. I checked my ‘/var/log/httpd/error_log’ for segfault errors and found plenty of them. I tried to find the source of the segfault issues by using a URL they told me to follow:
Instructions on backtrace generation here:
http://whoiscart.net/auracle/kbview.php?act=66&select=C1
I ran through those steps and it turns out that as soon as I run GDB, and then ‘run -x’, the httpd process completely stops running basically. So there’s no way for my to narrow the problem/provide them backtrace info. They were willing to generate the backtrace for me (nice guys!) if i gave them root access to my server, but I have yet to do that.
In the interim, when someone places an order and pays immediately by Paypal, it DOES in fact click both “yes” buttons (verify and process) and sends out the Invoice and the WhoisCart Receipt emails. Verify that that works for you. If it does, you could just modify your receipt template file to include a seperate box with Interworx info. For the URL, just put “www.<yourdomain>.com” and for the other 2 (username and password), just copy the contents from the WhoisCart (blue) box.
Hope this somewhat helps - if you have any progress fixing this situation, please be sure to let us know. I’m sure we’re not the only 2 with this problem!
Thanks.
Running:
RedHat 9
Hi Alexandre =)
I’m sure his message wasn’t meant to be taken that way at all - in his defense. He just seems frustrated, which is understandable given the circumstances.
You guys really DON’T “pass the buck” on support at all - you’ve proven that time and time again. Thanks for the continued support.
However, I’m not sure how many of your ‘32’ clients are actually using the HAPI process. Are you sure they’ve all got it working perfectly? Because it seems as if Perry’s having the same issues as me, and we’re running 2 seperate OSes with all our Interworx updates (at least I am) and still experiencing PHP Segfault errors.
Anyways if anyone who has got it working can chime in and tell us what you did different, it would be greatly appreciated =)
Hi Int,
I do appreciate your comments, and have noted them - we keep case logs very religiously.
That yours works at all through segfaults is very intriguing however. Perry’s just dies outright. Understand that we have over 3000 active clients at present time, of which a very small percentage use Interworx. Were this a problem with the cart outright, we’d have pandemonium on our hands, and quite likely wouldn’t have 3000+ customers to begin with. I agree with you that it’s true that where other Interworx clients haven’t posted support tickets regarding these issues, that this doesn’t mean that they are working in segfault-free environments. As a software company, we have to work on the ‘ok until reported otherwise’ assumption however. We cannot force tickets out of people.
That we have 3000+ clients however, where only Interworx clients report this problem, remains that the only constant is Interworx. I cannot see how Interworx could be to blame, but it is the sole constant thus far. This plainly, is all we have to work with from an objective point of view. Without it having been mentioned at any step, I wrote a message to Zend on the sidelines regarding your segfaults believing that they might be to blame, and this was their response:
Dear Sir,
In the next few days we will release a new version of Optimizer (2.5.10)
that includes many bug fixes.
Please download and install it, after it is availible from:
Please update me with the results.
Please do not hesitate to contact us with any additional questions.
Regards,
Alexandra Shpindovsky
Technical Support Engineer
Mail: alexandra@zend.com
Zend - The PHP Company
In many ways, while we do not support server side problems, I’m hoping the above will interject as the magic solution to these issues.
Regards.
A.
Hi Alexandre,
With respect to Interworx, I have actually been quite certain for awhile now that Interworx is in fact the one causing issues here. I remembered having issues back when I was using a different order processor, also a PHP script but much much more basic. I had trouble getting the order form to work and was told to check the /var/log/httpd/error_log and that is when I first noticed Segfault errors. A bunch of us using Interworx had issues with getting PHP to update, so the Interworx-PHP combination itself could be what is to blame here.
Anyways i’m as hopeful as anyone else that the Zend update resolves all our issues. However, if it is not, I suppose we will have to ask someone from Interworx to look into our Segfault errors.
Thanks for the reply, as well as the update on Zend’s upcoming release.
Hi All,
Let me just say I dont want to start a flame war or anything with these comments its just my sense of homour. If you dont have one then might be best skip this post.
Well it seems to me that there is alot of “It’s not our fault, its theres” when maybe the dev’s of these two programs should be saying “lets sort this out”
So far I have the following list of whos at fault here.
OS
Whois.cart
Interworx
and now Zend
and 50% of the world is saying ‘it’s windows’
Have I missed any? 
On the note about the 30+ interworx customers. Alex are you sure they are using the product and have not just brought a licence, found it does not work and moved on?
It seems a big shame that it does not work as I have said before and will say again it fitted my needs, its not complex easy to use. I have also spent time and money with getting it all to fit into my site. And now when its all set and ready to run we have this issue. I asked 2 linux/php experts about this issue and they said they cant even begin to debug it because its all encoded. Its all over my head at the end of the day im just a end user if I was not I would not require interworx / whois.cart
I guess the USA has woken up now and maybe someone from interworx could check somethings and give some feed back, if any of the interworx guys need access to my box drop me an email.
Look forward to the fix 
instead of 100’s of replys to this email 
Perry,
I don’t want to blame anything at this point since I can’t even tell you the exact problem.
PHP is crashing at some point if I remember the problem correctly. We provide PHP with iworx-cp so we’re being asked about it and that’s cool with me. What I’d like to do is try to rule out things (software, hardware, etc etc) instead of blaming. At least then the set of things to blame is smaller :).
If I remember correctly you’re on Fedora 3. I would try out their PHP package. If it works, then we know it’s most likely some config option with the PHP we provide. We don’t provide PHP because you have to use our PHP, we simply do it as a courtesy to you and if it’s not working out you’re free to try out others. The stock PHP from Fedora 3 may fit you better.
If Saeven wanted to, we could provide an iworx-cp box for him to run his product un-encoded for testing, and again, we could rule in/out the encoding.
Finally, the Zend optimizer may be the problem. We can rule it in/out/neither by upgrading to it when its available.
There are options here Perry, the quickest / easiest of which may be just to switch to Fedora 3’s PHP. Alternately you could use the PHP that you’ve mentioned having no issues with on other servers. Again, the PHP we provide isn’t required, it’s simply there as a courtesy. We had been flooded with people frustrated with the lack of updates from RedHat/CentOS etc for PHP and decided to fill this gap.
Chris
Hi Chris,
The linux guy put all dif versions of php with the same results. So he put back the your version.
Perry
Hi Chris,
I’m having the same Segfault problems and i’m not even running a FC3 box - mine’s a Redhat 9 box. HOWEVER, my server does process the requests, as Alexandre pointed out (which was weird to him), it just doesn’t send out the Interworx welcome email/details.
I would be willing to give another PHP version a try - but I believe I have a seperate PHP installed anyways - which I once upgraded manually because Interworx wouldn’t run the update on it’s own. If that is the case, that is not the issue. However, would it be possible for you to provide me with instructions on how to safely remove my current PHP and install the default Redhat 9 PHP, without any issues? =) I don’t want my site or customer’s PHPs to be down - or if they are down for a few minutes, this would all have to be resolved during the night/early morning sometime.
Thanks for the reply and for looking into this problem for us =)
Perry,
I’d have him try the Apache / PHP that you have working on another box. If the PHP swapout didn’t work I would lean more toward it being Zend’s issue. If we could test encoded vs. non-encoded that would be helpful in ruling in/out Zend. Either way, a Fedora 3 box running Fedora’s Apache / PHP is almost no different than the same setup but with IWorx-CP added. We don’t mess with any of the libraries or other dependencies needed by Apache / PHP.
int, do you get the same segfault as Perry, that is, the one pertaining to:
#7 0x07e98bd2 in get_module () from /usr/local/Zend/lib/Optimizer-2.5.7/php-4.3.x/ZendOptimizer.so
Saeven, is there an ioncube encoded version available so we could rule in/out zend?
Chris
Alex are you sure they are using the product and have not just brought a licence, found it does not work and moved on?
Definitely - they would have surely asked for us to honor our refund policy, http://whoiscart.net/license.htm - and although not eligible, we would have honored their requests. No refund requests in 2+ years now.
We don’t provide PHP because you have to use our PHP, we simply do it as a courtesy to you and if it’s not working out you’re free to try out others. The stock PHP from Fedora 3 may fit you better.
PHP isn’t to blame here though, the segfault is occurring at
_dl_sysinfo_int80 ()
which is a kernel function, previously called from:
/lib/tls/libc.so.6
which is a glib shared object.
Look at the signal: SIGTERM - this is clear. It means that the program is disliking an instruction and explicitly calling exit( int );
It isn’t impossible that this is a Zend Issue. I’ve heard some inexplicable problems after the PHP 4.3.9/Optimizer 2.5.7/Encoder 3.6 suite came into being. The suggestion to wait for 2.5.10, which Zend conveys to me is to be released soon, is definitely the best. If this doesn’t solve anything, I’ll continue with them whilst I release an IonCube encoded version (which we dropped) for the sake of elimination.
Regards.
A
Chris,
I only have an old cobalt RAQ which we took out and replaced with the new server. I can do an install on that no problem.
Couple of Q for you and whois.cart will I beable to install without issue as licence are locked to domains or IP’s?
If not I will try and do it all tomorrow…
Cheers,
Perry
This is the same fault as I have.
Just did the update and ran a test order quick.
I received the same 2 emails as I was receiving before - no sign of a Siteworx/Interworx email (or a WhoisCart with Interworx login details).
As for my ‘/var/log/httpd/error_log’ - here are all of today’s entries. Note that I have a cron job set to shutdown and restart the httpd and mysql processes at 3:25am - so THAT would explain the sigterm! Those are 100% normal - right? As for the one at 3:04am - that one I can’t explain. No cron jobs there.
Sounds like Perry’s problem is isolated - the sigterms, from my understanding, on my server are perfectly fine:
[Thu May 19 01:31:12 2005] [error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache' for writing (store) [Thu May 19 03:04:11 2005] [notice] caught SIGTERM, shutting down [Thu May 19 03:04:13 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Thu May 19 03:04:13 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain’ does NOT match server name!?
[Thu May 19 03:04:14 2005] [notice] mod_python: Creating 32 session mutexes based on 150 max processes and 0 max threads.
[Thu May 19 03:04:14 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain' does NOT match server name!? [Thu May 19 03:04:14 2005] [notice] Digest: generating secret for digest authentication ... [Thu May 19 03:04:14 2005] [notice] Digest: done [Thu May 19 03:04:15 2005] [notice] Apache configured -- resuming normal operations [Thu May 19 03:25:00 2005] [notice] caught SIGTERM, shutting down [Thu May 19 03:25:02 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Thu May 19 03:25:02 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain’ does NOT match server name!?
[Thu May 19 03:25:03 2005] [notice] mod_python: Creating 32 session mutexes based on 150 max processes and 0 max threads.
[Thu May 19 03:25:03 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain' does NOT match server name!? [Thu May 19 03:25:03 2005] [notice] Digest: generating secret for digest authentication ... [Thu May 19 03:25:03 2005] [notice] Digest: done [Thu May 19 03:25:04 2005] [notice] Apache configured -- resuming normal operations [Thu May 19 12:15:06 2005] [notice] Graceful restart requested, doing restart [Thu May 19 12:15:07 2005] [notice] mod_python: Creating 32 session mutexes based on 150 max processes and 0 max threads. [Thu May 19 12:15:08 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain’ does NOT match server name!?
[Thu May 19 12:15:08 2005] [notice] Digest: generating secret for digest authentication …
[Thu May 19 12:15:08 2005] [notice] Digest: done
[Thu May 19 12:15:09 2005] [notice] Apache configured – resuming normal operations
Apache restarting at 12:15 was due to the Zend update/restart.
Also at 12:15 - the errors there I believe are simple errors because “localhost.localdomain” isn’t defined right somewhere in Apache, not in WhoisCart.
This quite possibly, for me anyways, may not be a WhoisCart cart problem afterall.
EDIT:
Actually when I process an order, sometimes when I hit process it doesn’t work, and the second time I hit it, it works and the order appears TWICE in both “hosts” and in the email sent out.
Also, for every order, I get the follow error in the error_log:
[Thu May 19 12:39:42 2005] [notice] caught SIGTERM, shutting down
[Thu May 19 12:39:43 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu May 19 12:39:43 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain' does NOT match server name!? [Thu May 19 12:39:44 2005] [notice] mod_python: Creating 32 session mutexes based on 150 max processes and 0 max threads. [Thu May 19 12:39:44 2005] [warn] RSA server certificate CommonName (CN) localhost.localdomain’ does NOT match server name!?
[Thu May 19 12:39:44 2005] [notice] Digest: generating secret for digest authentication …
[Thu May 19 12:39:44 2005] [notice] Digest: done
[Thu May 19 12:39:45 2005] [notice] Apache configured – resuming normal operations
Hi,
I have updated to the latest Zend. I even kept my fingers crossed and my toes.
I placed an order for hosting.
System sent me a email to say an order had been placed and I should visit the admin area, which I did, I told the system the payment was recieved and to process the order. I knew it failed as soon as I pressed the Process button and it never changed from Process to yes.
A second later my email arrived and no login details for the interworx details 
I then thought check the log file “interworx_1_log.htm” but I still see “XMLRPC Error”
So bad news im afraid
I dont think this is linked to the problem because I get these if I even make a site via the intworx control panel.
As soon as a site is made I receive the following email from “Cron”
cd /home/interworx/cron ; ./iworx.pex --fively
Subject: Cron <iworx@delly> cd /home/interworx/cron ; ./iworx.pex --fively
ERROR: start (1116519147) should be less than end (1116519140)
ERROR: start (1116519147) should be less than end (1116519140)