Pages

Showing posts with label LINUX. Show all posts
Showing posts with label LINUX. Show all posts

Friday, February 16, 2024

Suphp Installation

Installing suPHP on a server using cPanel and EasyApache is a straightforward process but requires careful attention to detail. suPHP is a tool for executing PHP scripts with the permissions of their owners, enhancing the security of the server. Here's a detailed guide on how to install and configure suPHP:

Step 1: Launch a Screen Session

Before you start, it's recommended to run EasyApache within a screen session. This ensures that the process continues running even if your SSH session is interrupted.
screen -S ea
This command starts a new screen session named "ea."
Step 2: Run EasyApache

Now, initiate the EasyApache script. This script provides a text-based interface for configuring Apache and PHP.
/scripts/easyapache
Step 3: Select Mod SuPHP

Within the EasyApache interface, navigate to the "Exhaustive Options List" and find "Mod SuPHP." Select it by pressing the spacebar. Make any other adjustments as needed for your server environment, then proceed to compile and build Apache and PHP with your new settings.

Step 4: Build the Configuration

After selecting Mod SuPHP and any other required options, follow the on-screen instructions to complete the build process. This might take some time depending on your server's specifications and the options selected.
Step 5: Configure suPHP

Once EasyApache has finished building, you can enable suPHP on your server with the following command:
/usr/local/cpanel/bin/rebuild_phpconf 5 none suphp 1

This command sets PHP5 to use suPHP as the PHP Handler and enables suEXEC, which is necessary for suPHP to function correctly.
Step 6: Verify the Configuration

To ensure that suPHP has been correctly configured, use the following command to display the current PHP handler setup:
/usr/local/cpanel/bin/rebuild_phpconf --current

You should see output indicating that PHP5 is using suPHP and that suEXEC is enabled.
Step 7: Restart Apache

For the changes to take effect, restart the Apache service:
/scripts/restartsrv_httpd
Step 8: Check suPHP Log and Adjust Permissions

Finally, you can check the suPHP log file for any errors or messages:
/usr/local/apache/logs/suphp_log
If you encounter errors related to file permissions, suPHP requires directories to have 755 permissions and files to have 644 permissions. Use the following commands to set permissions correctly for PHP files and directories within your web content:
find . -type d -exec chmod 755 {} \; find . -type f -exec chmod 644 {} \;
Run these commands within the root directory of your website(s).

Conclusion

Following these steps will install and configure suPHP on your cPanel server, enhancing the security by executing PHP scripts with the permissions of their owners. Be sure to monitor the suPHP log file for any errors and adjust file permissions as necessary to avoid common issues related to improper file permissions.

All the databases are showing size 0 MB in cpanel

When managing a server with cPanel, encountering an issue where all databases are showing as 0 MB in size can be concerning. This typically indicates a configuration issue rather than actual data loss. The solution involves a simple tweak in the cPanel configuration file and running a script to update the database cache. Here's a step-by-step guide to resolve this problem:

Step 1: Access the Server

First, you need to access your server's command line interface (CLI). This is usually done via SSH. Once logged in as the root user, you're ready to proceed to the next step.

Step 2: Edit the cPanel Configuration File

The cPanel configuration file, cpanel.config, contains various settings that control how cPanel behaves. To edit this file, you'll use the vi editor, a widely-used text editor in Unix-like operating systems. The command to open the file is:vi /var/cpanel/cpanel.config

Step 3: Modify the Configuration

While in the vi editor, you're looking to change the setting that includes database sizes in the disk usage calculations. By default, or due to a misconfiguration, this setting might be disabled (set to 0). You need to find the line that reads:
disk_usage_include_sqldb=0
and change it to:
disk_usage_include_sqldb=1

This change tells cPanel to include SQL database sizes in its disk usage calculations.

To edit in vi:
Navigate to the line using the arrow keys.
Press i to enter insert mode.
Make the necessary changes.
Press Esc to exit insert mode.
Type :wq and press Enter to save the changes and quit vi.

Step 4: Run the Update Script

After saving the changes to the cpanel.config file, you'll need to update the cPanel database cache. This is done by running a script included with cPanel:/scripts/update_db_cache


This script will process the change you've made and update the database sizes accordingly.
Conclusion

Following these steps should resolve the issue of databases showing as 0 MB in size within cPanel. It's a straightforward fix that addresses a common configuration oversight. After running the update script, you can verify the changes by checking the disk usage statistics in cPanel again. If the problem persists, it might be wise to consult with cPanel's documentation or reach out to their support for further assistance.

Monday, January 22, 2024

Resolving Disk Quota Discrepancies in cPanel and Server

Occasionally, you might encounter discrepancies between the disk usage reported by cPanel and the actual usage on the server. This situation can be puzzling and frustrating. This guide provides a step-by-step solution to resolve these differences and ensure that cPanel reflects the correct disk usage.

Step 1: Log in to the Server

Access your server as the root user via SSH:

ssh root@server

Once logged in, you'll have the necessary permissions to perform system-wide operations.

Step 2: Run Reset and Fix Quota Scripts

cPanel provides scripts to reset and fix quotas. Running these might resolve the issue immediately.

Reset Quotas: This script resets user quotas to ensure they're in sync:

/scripts/resetquotas

Fix Quotas: This script attempts to correct any quota problems:

/scripts/fixquotas

Step 3: Verify the Quota Adjustment

After running the scripts, check if the disk quota issue is resolved. If the discrepancy persists, proceed to the next step.

Step 4: Use Screen for a Detailed Quota Check

If the issue is still unresolved, it's time to perform a more thorough quota check. Using screen allows this process to continue running even if your SSH session is disconnected.

Start a Screen Session:

screen -S ea

Run Quotacheck: In the screen session, force a check and update of disk quotas for all filesystems:

quotacheck -avfumg
  • -a: Check all filesystems.
  • -v: Verbose mode.
  • -f: Force checking even if the system believes quotas are correct.
  • -u: Check user quotas.
  • -m: Do not try to remount the file system read-only.
  • -g: Check group quotas.

Exiting Screen: To detach from the screen session without stopping the running process:

Ctrl + A + D

Re-enter Screen: If you need to go back to your screen session:

screen -x

Step 5: Completion and Verification

Once the quotacheck process completes, you should see a summary of the directories and files checked:

quotacheck: Scanning /dev/simfs [/] done quotacheck: Checked 90761 directories and 772655 files.

Check in WHM: Now, verify whether the disk usage in cPanel reflects the actual usage on the server:

  1. Log in to WHM.
  2. Navigate to the account in question and review the disk space usage.

Conclusion

Resolving discrepancies between cPanel and server-reported disk usage can usually be handled through the provided scripts and a thorough quota check. Remember, keeping your cPanel and server environment updated and regularly monitored is crucial for maintaining accuracy and performance. If the issue persists after these steps, consider contacting cPanel support or a server administrator for further assistance.

Friday, January 12, 2024

Enabling Remote Connections to PostgreSQL Database

Introduction:

By default, PostgreSQL is configured to be accessed only from the local machine. To access your PostgreSQL database remotely, you'll need to modify a couple of configuration files: pg_hba.conf for client authentication and postgresql.conf for listening addresses. This guide will take you through the steps to enable remote connections.

Understanding the Error

When remote connections are not enabled, attempting to connect to your PostgreSQL server from a remote machine will typically result in the following error:

psql: could not connect to server: Connection refused

Configuring PostgreSQL for Remote Access

Step 1: Modify pg_hba.conf

1. Open the pg_hba.conf file located in your PostgreSQL data directory (/var/lib/pgsql/data/ or similar):

nano /var/lib/pgsql/data/pg_hba.conf

2. Add a new line under the IPV4 local connections section to specify which hosts are allowed to connect:

# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host all all 127.0.0.1 255.255.255.255 trust
  • To allow connections from any IP:
    host all all 0.0.0.0/0 trust
    Note: Allowing connections from any IP (0.0.0.0/0) can be very insecure if proper measures are not taken to secure the database.

3. Save and exit the file.

Step 2: Change the Listen Address in postgresql.conf

1. Open the postgresql.conf file:

nano /var/lib/pgsql/data/postgresql.conf

2. Find the line that specifies listen_addresses and change it to:

listen_addresses = '*'

This setting allows PostgreSQL to listen for connections from any IP address.

3. Save and exit the file.

Step 3: Restart PostgreSQL

Apply the changes by restarting PostgreSQL:

service postgresql restart

or

systemctl restart postgresql

Testing the Remote Connection

1. On the remote machine, attempt to connect to your PostgreSQL server:

psql -U postgres -h YOUR_SERVER_IP
  • Replace YOUR_SERVER_IP with the actual IP address of your PostgreSQL server.

2. If everything is configured correctly, you should be prompted for a password and then given access to the PostgreSQL interactive terminal.

Conclusion

You've now configured your PostgreSQL server to accept remote connections. This setup is essential for development and production environments where database access is required from remote locations. Remember, allowing remote connections to your database can expose it to security risks. Always ensure your database is secured with strong passwords, firewalls, and consider using SSL connections. If you're opening up your database to the internet, it's crucial to implement additional security measures and regular security audits.