Change website

From Jan 16 2015,


All post content will be move to we's offical website with many content...

Can access website here: http://justox.com

Thanks for your visit!

Showing posts with label PHP. Show all posts
Showing posts with label PHP. Show all posts

Friday 27 December 2013

10 Open Source Web-Based Project Management

Project management software is not just for managing software based project. It can be used for variety of other tasks too. The web-based software must provide tools for planning, organizing and managing resources to achieve project goals and objectives. A web-based project management software can be accessed through an intranet or WAN / LAN using a web browser. You don't have to install any other software on the system. The software can be easy of use with access control features (multi-user). I use project management software for all of our projects (for e.g. building a new cluster farm) for issue / bug-tracking, calender, gantt charts, email notification and much more.

Tutorial Linux: 25 PHP Security Best Practices For System Administrator

PHP is an open-source server-side scripting language and it is a widely used. The Apache web server provides access to files and content via the HTTP OR HTTPS protocol. A misconfigured server-side scripting language can create all sorts of problems. So, PHP should be used with caution. Here are twenty-five php security best practices for sysadmins for configuring PHP securely.

Creating a PHP ICO Creator for Favicons

For the past couple of weeks, I have worked on creating a PHP library to create ICO files. This has been difficult as all the documentation for the ICO format is either sparse or not completely documented.

Thursday 19 December 2013

PHP 500 Internal Server Errors

500 Internal Server Errors are one of the most common PHP issues that I see customer experience, and it will occur mostly on servers with suPHP or PHP running as CGI.  These errors can be caused by something on the server, or an issue on the user’s site. Here ‘s what you should do if you see errors:
Check the logs
You can solve most problems quickly just by looking at the logs:
/usr/local/apache/logs/error_log
/usr/local/apache/logs/suphp.log
Here are some common errors:
SoftException in Application.cpp:357: UID of script "/home/user/public_html/test.php" is smaller than min_uid
SoftException in Application.cpp:422: Mismatch between target UID (511) and UID (510) of file "/home/user/public_html/test.php"
SoftException in Application.cpp:264: File "/home/user/public_html/test.php" is writeable by others
These are all permission/ownership issues, indicating that the owner of the PHP file being called in incorrect, or the permissions are higher than what is allowed in suphp.conf.
Invalid directions in .htaccess
If you’re running PHP in CGI or suPHP mode, you can’t use php_flag or php_value directives in .htaccess – you either need to use htscanner to allow Apache to parse those commands, or make php-related changes in php.ini within the user’s account. You can check the Apache error log in /usr/local/apache/logs/error_log to see if you get something like this:
/home/user/public_html/.htaccess: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration
If the error log indicates a problem with .htaccess, you need to remove the directives indicated and make sure your ssyntax is correct, and that they are in the correct places.
Incorrect ownership or permissions
PHP scripts and their immediate parent folder will usually have permissions limits when PHP runs in CGI/suPHP mode. By default, PHP files and their parent folders can not have group or ‘other’ writable permissions, and cannot be owned by a user on the system other than than the user that owns the home folder it is located in. Additionally, cPanel’s implementation of suPHP does not allow PHP to execute via browser from locations that are not inside a user’s home folder. The first thing you should check is that the PHP script and its parent folder(s) are not writable by ‘group’ or ‘other’, or owned by a different system user. You can usually see if this is an issue by tailing the suphp log in /usr/local/apache/logs/suphp.log, or whatever the suphp.conf has set as the log location.
You can adjust suPHP’s permissions allowances in /opt/suphp/etc/suphp.conf to allow ‘group’ and ‘other’ writable permissions if it’s necessary by modifying these values:
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

If the problem is with the min_uid value being too low (such as if you’re running a PHP script as root), you can also modify the “min_uid” and “min_gid” values to be more permissive. Changing anything in the suphp.conf requires a restart of Apache.
SuPHP binary missing its “sticky” permissions
Take a look at the suphp binary. It should look a bit like this, and in most shells, will be highlighted in red:
-rwsr-xr-x 1 root root 341K Mar 30 12:25 /opt/suphp/sbin/suphp*
If it’s missing the ‘s’ in the permissions column, you need to re-add the sticky bit to allow users on the system to execute it properly:
chmod +s /opt/suphp/sbin/suphp

Automating Apache and PHP Updates

A lot of hosts that deploy a large number of servers are automating updates instead of running them manually. While cPanel updates can be automated as well, it’s become a common question of how to automate Apache and PHP updates across a large number of servers without having to manually run EasyApache on each server, which can be a very time-consuming process. If Apache and PHP were built via RPM, you could simply run a yum update. However, since they are built with EasyApache it’s not quite as simple as updating an RPM, but it’s still very easy to automate.

PHP Security Vulnerability

There is a vulnerability in certain CGI-based setups (Apache+mod_php and nginx+php-fpm are not affected) that has gone unnoticed for at least 8 years.
Some systems support a method for supplying a [sic] array of strings to the CGI script. This is only used in the case of an `indexed’ query. This is identified by a “GET” or “HEAD” HTTP request with a URL search string not containing any unencoded “=” characters.

Wednesday 18 December 2013

XCache v3.0.1, More Performance For PHP Apps

After writing about how to Boosting PHP Apps Performance with APC, i finally got time to consider making comparison about those two. As i wrote in previous post, this will maybe not meet your requirements and you will maybe need to use APC instead.

After removing APC, we installed XCache v3.0.1 and then run few tests again and again with AB and Tsung, with APC we had about 300 requests per second, but guess what.. with XCache we got almost same number of requests per second without any configuration eg. out of the box!
Now what i wanted to do is try to find a way how to maximize number of requests per second. Here is preview of my final config :
# enable xcache module for php
extension=xcache.so

# we want admin interface, setup username and password (password is in MD5) and location to xcache admin GUI is at /usr/share/xcache/htdocs/ -- Debian/Ubuntu
xcache.admin.enable_auth = On
xcache.admin.user        = ""
xcache.admin.pass        = ""

# for my scripts, its enough to have 128MB op code cache size, anyway i don't use variable caching with xcache
xcache.size             = 128M
# how xcache get shared memory
xcache.shm_scheme       = "mmap"
# i want 4 chunks for splitting memory, you can also test a bit with 2-4-6, depending on your hardware
xcache.count            = 4
# more slots means more memory usage but is faster
xcache.slots            = 8K
# how long we want file to be in cache (in milliseconds), 0 means forever
xcache.ttl              = 0
# garbage collection interval, 0 means never
xcache.gc_interval      = 0

# it's same as above but for variables, since im not using variable caching i will disable it
xcache.var_size         = 0M
xcache.var_count        = 0
xcache.var_slots        = 0K
xcache.var_ttl          = 0
xcache.var_maxttl       = 0
xcache.var_gc_interval  = 0

xcache.test             = Off
xcache.readonly_protection = On
xcache.mmap_path        = "/tmp/xcache"
xcache.coredump_directory = ""
# we want to cache, so we will enable it, if size = 0, opcode caching is disabled
xcache.cacher           = On
# statistics for opcode caching if file updated
# Thanks David : it determines whether Xcache/PHP check the filesystem to see if the file has changed or not
xcache.stat             = On
# didn't find what this gives, there is no better performance because that so i will just disable it
xcache.optimizer        = Off

# those guys can hur your performance, should be enabled only on debug
xcache.coverager        = On
xcache.coveragedump_directory = ""
After we checked and tested with AB, ab -c 10 -n 100 http://www.codestance.com/, we find that normally have about 450-470 requests per second which is better than APC, check this out :
Concurrency Level:      10
Time taken for tests:   0.209 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2414800 bytes
HTML transferred:       2383300 bytes
Requests per second:    463.41 [#/sec] (mean)
Time per request:       98.948 [ms] (mean)
Time per request:       9.895 [ms] (mean, across all concurrent requests)
Transfer rate:          248729.37 [Kbytes/sec] received
If you find this interesting, try it yourself and watch performance improvement after APC.
Please note that you need to run dozens of tests and after changing any parameter you will need to reload php to see any results improvement. You can also write a comment about your tests so we can make better comparison :)
Happy Hacking !