Easyapache-4 News!!!

EasyApache 4 was introduced in cPanel & WHM version 11.52 and has grown into a stable  product. As of version 58 EasyApache 4 is out of BETA, and is the default for any new cPanel installation.

Why EasyApache 4  I want to tell you :

  • Building with EasyApache 4 is Fast

    No need to full recompile of Apache and PHP for adding new module. With EasyApache 4 deliver Apache, PHP, and our supported PHP modules as RPMs, which means that adding a new module takes seconds.

  • Updates are  Automatic  with EasyApache 4

    Since EasyApache 4 is all RPM based, the operating system automatically takes care of updates for you

  •   PHP7 Support included in EasyApache 4

PHP7 will only be available for cPanel & WHM customers as part of EasyApache 4.             cPanel  already considering adding PHP 7.1, which just entered its third Alpha.

  • Multiple versions of PHP supported :EasyApache 4

    With cPanel & WHM version 58, We are  adding the ability to mange multiple PHP versions from WHM.

  • Easy to switch to EasyApache 4

    Switching  on easyapache4 is easy to do using our simple command-line script, and the conversion process requires no additional work from you

  • All  EasyApache RPMs are open source and available on github! Advanced users who want to customize the EasyApache 4 RPMs provided by cPanel can do so with ease!


So Get Set Go!!!!!

What is BCC in an eMail


BCC is a function used in emails and have an interesting purpose in some cases. An average email recipient has three classes, the first is the usual “To” recipient “CC” and finally the “BCC”. The first one is intended for the main recipients of the email, the second is for those recipients who are to receive a copy of the mail, and finally, the BCC who will receive a copy of the email but their email will not be seen by the other recipients. The usefulness of the BCC is to allow a long list of people interested in receiving the email, but for some reason they want to remain hidden.

The “To” field is for sending mail to people who are active in a project or subject of the email. This field addresses all visible together by interest of the email. This is because it is assumed that all are related to work and therefore have to keep in touch. On the other hand, the “CC” field are people who will not directly addressed email, and can also be interesting to know their e-mail each other.

The “BCC” field may be people who are related in some way to the job or project, but it is not essential that your email addresses are known. This can be for several reasons. The most common use for the primary recipient does not know who is receiving a copy of the email. While this can be done easily by a second copy of the message body and by forwarding the BCC field allows us to do this in a simple way and in a single step.

The BCC recipient will see the main direction on who is sending the mail (the “To” field), but the main target will see it is the only one who is sending the email. In mailing lists, the BCC camp is normally used as a courtesy for individuals who are part of the list. Even if everyone agrees to share your e-mail, have a mailing list too long is a risk of spam. It is also a risk for the subject of certain viruses, which include all the email addresses to replicate. The BCC field stops get all directions.

The meaning of BCC is Blind Carbon Copy, and is a term that predates the computers we know. At other times, when letters were written, it was done alternating pages of carbon paper between normal paper where it was written. When writing a letter several copies were made. Addresses and greetings were often left blank during the carbon copy, and then added by hand later. In this way the recipient does not know who else was receiving the letter.


Dealing against SQL Injections

SQL Injection (SQLI) is a code injection technique. Here, the attacker adds Structured Query Language code to a web input box. SQl is the universal language of databases and the injected SQL commands, which alter SQL statements, can compromise the security of a web application. SQLI is considered as one among the major web application vulnerabilities. It is one of the common mechanisms used by hackers to steal organizational data.

Mostly technologies built in dynamic script languages are more vulnerable like ASP.NET, PHP, JSP, ASP etc. Wide knowledge on SQL queries is what is required to make SQLI possible. This simplicity of SQL injection has accelerated its popularity. The attacker gains access to databases mainly because of vulnerability in the code used and the displayed results of sent SQL queries. Attackers can also be detained by implementing high security to the database.

SQL injection types that can be executed within a web server are:

Poorly Filtered Strings, Incorrect Type Handling, Signature Evasion, Filter Bypassing, Blind SQL Injection etc.

Considering the technicalities, you are under the risk of SQL injection if you have any applications which have not been routinely updated and patched and also if your code is not properly written. Most important precautions to be taken are data sanitization and validation. In sanitization, it has to be ensured that any submitted data should be filtered for any dangerous or unwanted characters. In validation, dangerous characters are blacklisted and only the characters allowed in the circumstances are whitelisted.

Some of the steps to mitigate SQL injection attacks are:

  •  Database Precautions: Use parameterised queries; restrict the web user with access only to the particular table.
  • Regular updates and patches: Routine updates and application of security patches can help identify vulnerabilities.
  • Firewall: Install a Web Application Firewall to help filter malicious data.
  • Perform basic security measures: Change the passwords of database accounts on a regular basis.
  • Coding: Always ensure your code’s functionality. Make the code writers responsible for checking the code and fix the security flaws within.

Hope this clears you how to deal with sql  🙂


free memory available in your Dedicated Server !!!

The command “free“ is used to check the RAM usages in the server. First of all, let us familiarise about the output of that command. The output of the command is as follows:

free o/p

In this example, the total amount of available memory is 1048576 KB. 570264 KB is used by processes and 478312 KB is free for other applications. Do not get confused, as the first line shows that 152280 KB is free! It is clear from the example that most of the memory used is for buffers and cache.

some terms related to cache:

Page Cache:

When a process like read or write a file is executed, a copy of the file is being modified in the main memory at the back end. Actually this scenario is performed by the kernel of the OS. So when the read or write process is executed, the kernel first looks for the copy of the file. And if no such copy exists it will create that copy of the file from the disk and writes back changes, whenever the modification is performed. So the memory taken up by these copies is called cached memory or page cache.

Clean Cache Page and Dirty Cache Page:

In this case, the kernel allocates one new page of cache memory and fills it with contents to be read out from the disk. When the user only reads the file the page will be marked as a ‘Clean’ cache page and when the user writes the file then that page will be marked as ‘Dirty’ cache page.

The memory issues in the Linux servers can be overcome by controlling the usage of page cache from the total memory in the server. Controlling of the page cache is done by changing the page cache kernel parameters. The lower the percentage, the more the system favors reclaiming unmapped page cache memory over mapped memory. High values (like the default value of 100) are not recommended for databases.

how we can limit the Page Cache or Cache Memory size.

Page cache phenomenon can consume as much memory as available in the machine for executing a process. It could be controlled only dynamically. And there is no particular kernel parameter to directly control page cache size. We could only limit the growth of page cache by tuning some configurable kernel parameters related to the page cache.

==> vm.vfs_cache_pressure (default = 100)

The parameter is used to control the tendency of the kernel to reclaim memory. Lowering this parameter causes the kernel to prefer and retain dentries and inodes caches and increasing this parameter beyond 100 causes the kernel to prefer to reclaim dentries and inodes.

==> vm.dirty_background_ratio ( default = 20)

The parameter is used to indicate the percentage of a system memory. Lowering this parameter will cause the pdflush to write away the dirty data sooner, and it will limit the size of the page cache.

==> vm.dirty_ratio (default=40)

The parameter is used to determine the percentage of the number of pages at which a particular process writes out the data for making the Dirty Cache page (Dirty data). Lowering this parameter will cause that particular process to write the Dirty data earlier, which will limit the page cache size.

==> vm.dirty_expire_centisecs ( default = 3000 , mentioned in milliseconds)

The parameter is used to determine the expiration time for the Dirty pages created so that they could equip themselves to be flushed out by the pdfush. Lowering the value will make more dirty pages to be eligible for flushing out, which would limit the page cache size.

==> vm.swappiness ( default=60)

The parameter is used to determine how soon you want to swap out the data during a process. The Higher parameter will cause the server more likely to swap and the lower parameter will cause the server less likely to swap. Thus, it will write data faster out of the disk and it will limit the Page cache size.

To change parameters dynamically on a running machine

Use the following command.

echo “500” > proc/sys/vm/vfs_cache_pressure

If you want persistent configuration make the modification to /etc/sysctl.conf.

sysctl -w vm.vfs_cache_pressure=”500″.

Stay tune to learn more on cache memory 🙂