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.
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
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:
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:
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:
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:
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.logHere 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.
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 :
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 !
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 !
Subscribe to:
Posts (Atom)