Help w/ KennonSoft GUI

[TheShniz]

I use a modified version of KennonSoft's GUI (much like the default PiaF) on "another distrib", but I'm having some difficulty using on PiaF...

When I use...
<? include("$DOCUMENT_ROOT/theme/modern/head.php"); ?>
...nothing is included.

When I use...
<? include("theme/modern/head.php"); ?>
...it *is* included, but nothing happens when you go to "index.php?admin=true"

What's strange is my includes using $DOCUMENT_ROOT *DO* work just fine on all the modifications to all other directories (ARI, FOP, etc.)... only the root directory seems affected.

Is there something in PiaF/PHP/Apache that could be stopping this?

 

[TheShniz]

!! Update !!

I changed KennonSoft's default settings (which I use) at the top of /index.php from:

// Default values
$host = $HTTP_SERVER_VARS["HTTP_HOST"];

to PiaF's default settings at the top of /index.php:

// Default values
error_reporting(E_ALL ^ E_NOTICE);
$host = $_SERVER['HTTP_HOST'];
$admin=$_REQUEST["admin"];
if (strpos($host,":")>0) :
$host = substr($host,0,strpos($host,":")) ;
endif ;

... now, when you click on 'Administration', it correctly redirects to /login.php , BUT ...

When I enter in the password (to log into Administration), it does nothing.

::sigh::

Loox like PiaF is using KennonSoft's 1.0, where mine is based off his 2.1 (if I remember right).

Help?!?

 

[jroper]

Hi

In order to get the Kennonsoft inteface to work properly with PiaF I had to do some light editing.

Most of the problems caused were because of the differences between php4 and php5. The Kennonsoft UI was designed for PHP4

This is probably the area that you need to look in order to fix your problems.

Yours

Joe

 

[TheShniz]

While I agree with you about PHP most likely being the issue, I don't believe the problem is going from PHP4 to PHP5. I think it must be the options PHP was installed with, specifically how they differ from the 'other distrib'.

With the 'other distrib', I'm able to use this same exact interface unmodified in both their PHP4/Asterisk1.2 and PHP5/Asterisk1.4 versions with no problem.

I'm going to keep poking around, but I wonder if I need some entries in php.ini or if PHP needs to be recompiled. Unfortunately I just don't know enough to pinpoint.

 

[jroper]

Hi

Look at the error logs for apache in /var/log/ These may give some indication as to why it is falling over.

What are you trying to do the kennonsoft gui that it does not do now?

Joe

 

[TheShniz]

The primary advantage of Kennonsoft's 2.1 over 1.x (outside of cleaner/better code), is it includes the ability to show/hide modules to the user via simple permissions. It is significantly more advanced than his 1.x, as he put a great deal of time into it (if you can remember that far back, lol).

I've also noticed that while Openfire does install just fine, the administration is inaccessible via port 9090. Further, I'm having difficulty with getting vTiger to display also (/crm).

PHP not withstanding, PiaF's Apache seems to be loading a different set of modules (atleast 1/2 are different) as seen via Webmin.

/var/log/httpd/* shows no errors, nothing out of the ordinary

!! Update !!

vTiger 5.0.4 supports PHP 5.2.x, vTiger 5.0.3 requires a patch to support PHP 5.2.x... I've now tried both 5.0.4 AND 5.0.3 w/ patch, and neither are accessible (via /crm)

 

[jroper]

Hi

I'll get a look at it.

Meanwhile, openfire at port 9090, you have opened up that port in the PiaF firewall haven't you?

There are some instructions for installing VTiger on this forum somewhere, and they did not have any problems as yours.

Joe

 

[TheShniz]

As for Openfire, lol, whoops... for others, what I did was add to /etc/sysconfig/iptables (above the commit):

# Allow connections to our Openfire - Web Administration
-A INPUT -p tcp -m tcp --dport 9090 -j ACCEPT
# Allow connections to our Openfire - Remote Administration
-A INPUT -p tcp -m tcp --dport 9091 -j ACCEPT
# Allow connections to our Openfire - XMPP Clients
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
# Allow connections to our Openfire - Flash Clients
-A INPUT -p tcp -m tcp --dport 5229 -j ACCEPT
# Allow connections to our Openfire - Connection Manager
-A INPUT -p tcp -m tcp --dport 5262 -j ACCEPT
# Allow connections to our Openfire - XMPP Servers
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT
# Allow connections to our Openfire - File Transfer
-A INPUT -p tcp -m tcp --dport 7777 -j ACCEPT
# Allow connections to our Openfire - External Components
-A INPUT -p tcp -m tcp --dport 10015 -j ACCEPT


No, there are no instructions here to install vTiger onto PiaF ... yes, I've seen the thread discussing vTiger and CRM's in general, with no report of difficulty.

For what it's worth, this is what I'm running to install vTiger... as instructed via vTiger.com

cd /usr/src
wget http://superb-east.dl.sourceforge.net/sourceforge/vtigercrm/vtigercrm-5.0.4.tar.gz
tar zxvf vtigercrm-5.0.4.tar.gz
mv /usr/src/vtigercrm /var/www/html/crm
cd /var/www/html
chown apache:root crm -R
cd /var/www/html/crm
chmod 664 /var/www/html/crm/config.inc.php
chmod 664 /var/www/html/crm/install.php
chmod 664 /var/www/html/crm/parent_tabdata.php
chmod 664 /var/www/html/crm/tabdata.php
chmod 664 /var/www/html/crm/cache/
chmod 664 /var/www/html/crm/install/
chmod 664 /var/www/html/crm/modules/Emails/templates/
chmod 664 /var/www/html/crm/Smarty/cache/
chmod 664 /var/www/html/crm/Smarty/templates_c/
chmod 664 /var/www/html/crm/storage/
chmod 664 /var/www/html/crm/test/contact/
chmod 664 /var/www/html/crm/test/logo/
chmod 664 /var/www/html/crm/test/product/
chmod 664 /var/www/html/crm/test/user/
chmod 664 /var/www/html/crm/test/wordtemplatedownload/
chmod 664 /var/www/html/crm/user_privileges/

 

[TheShniz]

!! Update !!

vTiger requires that those files I listed above have WRITE access enabled to actually work, which is why you see all those permissions of 664 above... however, for reasons I don't yet know, PiaF requires that those files also have EXECUTE permissions before vTiger even recognizes them.

As for my own modified version of Kennonsoft 2.1, this 'trick' doesn't work. I can tell authenticate.php is working, as it spits back 'incorrect password' if I enter in something wrong... but the user still is not redirected with admin access when entered correctly.

So, for PiaF and vTiger ONLY, it is required to do this...

chmod 777 /var/www/html/crm/config.inc.php
chmod 777 /var/www/html/crm/install.php
chmod 777 /var/www/html/crm/parent_tabdata.php
chmod 777 /var/www/html/crm/tabdata.php
chmod 777 /var/www/html/crm/cache/
chmod 777 /var/www/html/crm/install/
chmod 777 /var/www/html/crm/modules/Emails/templates/
chmod 777 /var/www/html/crm/Smarty/cache/
chmod 777 /var/www/html/crm/Smarty/templates_c/
chmod 777 /var/www/html/crm/storage/
chmod 777 /var/www/html/crm/test/contact/
chmod 777 /var/www/html/crm/test/logo/
chmod 777 /var/www/html/crm/test/product/
chmod 777 /var/www/html/crm/test/user/
chmod 777 /var/www/html/crm/test/wordtemplatedownload/
chmod 777 /var/www/html/crm/user_privileges/
chmod 777 /var/www/html/crm/logs/
chmod 777 /var/www/html/crm/modules/Webmails/tmp/

FYI, as reported by vTiger, UTF-8 Support is not included in PiaF (although not required, but highly recommneded)... it therefore references this file for more information:
http://www.vtiger.com/products/crm/help/5.0.4/vtiger_CRM_Database_UTF8Config.pdf

I followed the prescribed directions by adding the following to /etc/my.conf, but no luck:

[mysql]
default-character-set=utf8

[mysqld]
collation_server=utf8_unicode_ci
character_set_server=utf8
default-character-set=utf8
init_connect='SET collation_connection = utf8_general_ci'​

init_connect='SET NAMES utf8'

But then I used phpMyAdmin to run this command, and it worked just fine:

ALTER DATABASE vtigercrm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE​

utf8_general_ci

 

[TheShniz]

So far, In summary...

Openfire works = works; iptables, whoops
vTiger = works; permissions, don't like for but works
MySQL UTF-8 = works; alter database

Modified Kennonsoft GUI 2.1:

$DOCUMENT_ROOT not allowed under '/', use absolte path
Added 'Default Values' required
Authenticated Redirected still does NOT work

SOoooooooooooooo.........

I've been playing around w/ Apache/MySQL/PHP, and I got EVERYTHING to Work by simply replacing php.ini with the one from the 'other distrib'.

Now, I'm going through the php.ini to see what's effected the change :: sigh :: so very long, but hey... it's working!

 

[TheShniz]

Alrighty............ here's my final answer:

There are three (3) problems:


1.)


Kennonsoft's 2.1 GUI requires "register_globals = On" in php.ini, or else it's impossible to login when the user clicks on 'Administration' with the 'Default Values' at the top of /index.php. The obvious solution is to replace 2.1's values with 1.0's, such that:

Replace:

// Default values
$host = $HTTP_SERVER_VARS["HTTP_HOST"];

With:

// Default values
error_reporting(E_ALL ^ E_NOTICE);
$host = $_SERVER['HTTP_HOST'];
$admin=$_REQUEST["admin"];
if (strpos($host,":")>0) :
$host = substr($host,0,strpos($host,":")) ;
endif ;


2.)


Further, having "register_globals = Off" makes $DOCUMENT_ROOT not work in '/' (that is: /var/www/html/). It should be noted that $DOCUMENT_ROOT *DOES* work in all subdirectories.


3.)


Kennonsoft's 2.1 GUI does NOT function with "register_long_arrays = Off" and it must be commented out in php.ini, otherwise the system will not accept a valid password from the user. It should be noted that password validation still takes place, but login doesn't complete.

What this setting does is:

Disables registration of the older (and deprecated) long predefined array variables ($HTTP_*_VARS). Instead, use the superglobals that were introduced in PHP 4.1.0

Enabling long arrays by commenting out this line does NOT pose any security risks at all (unlike register_globals), and is ONLY in there as a perfomance measure.


X.)


As it is good security practice to keep "register_globals = Off" as is default in PiaF, I've kept it off and have instead removed $DOCUMENT_ROOT from all my '/' files (namely index.php, login.php, config.php). Additionally, I've also changed the 'Default Values'. And, last but not least, I've commented out register_long_arrays in php.ini.


Thanks Joe for taking the time, and giving some direction... I'm sorry for the novel, I should rename the topic as a blog, lol.

 

[jroper]

Hi

It would be appreciated if you could put up a full set of instructions from top to bottom for getting the KennonsoftGUI and vTiger installed.

To ensure that you comply with the GPL as far as modifying the Gui is concerned, can you ensure that any changes made to the GUI have your name and date of change against the changes, and the original is left in, but commented out.

This would be appreciated.

Joe

 

[TheShniz]

Yep, yep... already done, was in previous post
http://www.pbxinaflash.com/forum/showpost.php?p=5999&postcount=8

^^^ just replace 664 with 777 for vTiger, and that's it

My last post before this one are the two changes required for using Kennonsoft's latest GUI, basically two variables in /etc/php.ini. No modification to the GUI itself required.

 

[stuck]

TheShniz,
could you comment on your server hardware and the voice quality on that server which is hosting vtiger, and handling several agents accessing vtiger webpages, while simultaneously handling several SIP calls (with or without) transcoding...
I'm afraid of installing on the same server for fear of voice degradation when the agents (local or remote) access vtiger webpages.

 

[TheShniz]

I've never had any issues whatsoever as it relates to having Sugar, vTiger, or otherwise on the same machine...

The truth is, that the companies that *do* utilize the crm don't do so company-wide. That would reflect an enormous investment on their part... no, usually what happens is the sales people or call center agents latch on to it, and that's about it.

Now... just as if someone came to me with 1,000 extensions site, you know they're gonna blow past any capability of a single machine (ignoring redunancy, etc)... so if you know a sizable company is going all out on it, I'd without a doubt be putting it on a seperate system (distributed architecture). I've just not come up to anybody so quick to move their entire operations.

Finally, I'll also mention, that it's been brought up by another (I forget who) on another forum that echoes what I just told you from their own experiences (not unique). However, what they mentioned was, that they load cpulimit on all their machines to help ensure it to never be a problem (to combat the "what if's").

I think it just needlesly adds one more cog to an already complex system, so I forgoe cpulimit myself.

Now, if you want to talk about bringing a machine to it's knees... I've found the quickest way is through IO-intensive tasks (using as a file server).

The specs of machines that I run range from Core 2 Duo to Xeon, 1~2GB of Memory, always on Intel chipsets, never using hardware raid (always software). I just don't find Asterisk as cpu-intensive, and when it is... it's limited to a single core (maybe the big key here).

Sorry for the rambling, just thought I'd share

 

[stuck]

Thanks Shniz,
Unfortunately the server in question is only a P4 class cpu with 1gb ram. with ~6-7 concurrent voice channels (transcoding g729) I'm afraid that it may not be able to take the extra load from 8-10 vtiger connections. So I think I will install on a separate server. That way it's QOS priority can also be below PIAF.

 

[TheShniz]

If you're only talking about 8-10 people, I'd have no problem putting it on a P4 w/ 1GB... assuming this is a ~3GHz machine and not 1.8GHz of course.

The debate in your head should be concerning CPU Utilization, not QoS... vTiger is going to be port 80, and that's about it. Network Utilization from vTiger is close to nill as well.

The only question I'd have in my mind is the overhead from transcoding g729... I don't use that myself, so I have no basis to say how busy your CPU is already (I'd assume not much for 6~7 active channels).

At the end of the day, you loose nothing to put vTiger on the same machine... if for some strange reason it becomes an issue, it's trivial to simply move the db to another install on a seperate pc.

 

[stuck]

If you're only talking about 8-10 people, I'd have no problem putting it on a P4 w/ 1GB... assuming this is a ~3GHz machine and not 1.8GHz of course.

I believe it's a 2.8ghz, so I'm good there,

The debate in your head should be concerning CPU Utilization, not QoS... vTiger is going to be port 80, and that's about it. Network Utilization from vTiger is close to nill as well.

CPU utilization is certainly in my head, but since there are remote agents that will also access vtiger, the page data will be sent along the WAN and thus I'm concerned about the QOS...

At the end of the day, you loose nothing to put vTiger on the same machine... if for some strange reason it becomes an issue, it's trivial to simply move the db to another install on a seperate pc.

you're right, I might just try it and see how well it performs...

 

[stuck]

alright,
I've installed it both ways. On a PIAF server as well as on a Windows XP box. Both work fine. But the integration part was quite a handful. Using digital-worx.de's method, I had to patch every file manually and altered the ident.agi; created phpagi.conf in the windows box. The new fields are there in the pages and I'm able to add the extension information. But clicking on a number to call, doesn't pop up with a new window seems to be bug in my script somewhere. This occurs on both servers. I don't know where to start with the debugging. How did you the click-to-call to work?
And my ident.agi script doesn't work either, on the CLI shows return 0 and does not call up a new popup window to show the incoming caller either.

 

[jroper]

Hi

Can you have got your firewall open, and the correct IP address ranges in the manager_custom.conf files.

Joe