Linux - Resource Manager - Processes limitations (/etc/security/limits.conf)

In a multi-user environment, it's essential to maintain stability and ensure that no single user can consume resources to the point of affecting others or the system itself. The /etc/security/limits.conf file in Linux is a powerful tool for controlling user resource limits. This guide will explain how to use this file to limit user processes and other resources.

Understanding /etc/security/limits.conf

The /etc/security/limits.conf file allows you to set hard and soft limits for various system resources. A hard limit is the maximum value a user cannot exceed, while a soft limit is essentially a warning level.

Syntax

Each line in the /etc/security/limits.conf file has the following syntax:

<domain> <type> <item> <value>

• <domain>: User, group (prefixed with @), or wildcard (*) for default.
• <type>: Hard (hard) or soft (soft) limit.
• <item>: Resource to limit (e.g., nproc for the number of processes).
• <value>: Numerical value of the limit.

Example Entries

*               hard    nofile          65535
*               soft    nofile          4096
@student        hard    nproc           16384
@student        soft    nproc           2047
@student        hard    nproc           50
@student        soft    nproc           30

These lines set the maximum number of open files and processes for all users and specific limits for users in the student group.

Setting the Limitations

1. Open /etc/security/limits.conf:
   Use your preferred text editor (like nano or vim) to edit the file.

2. Modify or Add Entries:
   Based on your requirements, modify existing entries or add new ones following the syntax mentioned above.

3. Save the File and Exit:
   Once you've made the changes, save the file and exit the editor.

4. Restart the System (Optional):
   While most changes will apply immediately or on a new session, a restart ensures all services and users are started with the new limits.

Verifying the Limitations

To verify the limits for a particular user, switch to that user and use the ulimit command:

• Check Soft Limit for File Descriptors:

  ulimit -Sn
  

• Check Hard Limit for File Descriptors:

  ulimit -Hn
  

• Check Soft Limit for User Processes:

  ulimit -Su
  

• Check Hard Limit for User Processes:

  ulimit -Hu
  

Testing the Limitations

The infamous fork bomb :(){ :|:& };: is a bash function that recursively creates copies of itself. It's often used to test process limitations. Warning: This script can make your system unresponsive. Use it only in a controlled environment.

1. Ensure you're in a safe test environment.
2. Run the Fork Bomb:

   :(){ :|:& };:
   

3. Observe the Behavior:
   The system should prevent the script from creating processes beyond the set limit.

Conclusion

Correctly setting user limits is a critical task for system administrators to ensure a stable and fair environment for all users. By configuring the /etc/security/limits.conf file, you can prevent individual users from over-consuming resources and maintain the overall health of the system. Always test changes in a controlled environment before applying them to a production system.

Backing Up MySQL Database as a Restricted User

As a developer, you might find yourself in a situation where you need to back up a MySQL database, but you don't have full administrative privileges. While it's typically a sysadmin's job, knowing how to handle this can save the day. This guide provides a workaround for a common issue where restricted users encounter errors when attempting to dump databases.

Understanding the Error

When using mysqldump as a user with limited privileges, you might encounter the following error:

mysqldump: Couldn't execute 'show events': Access denied for user 'user'@'some-host' to database 'dbname' (1044)

This error occurs because the user doesn't have the necessary privileges to access database events. Fortunately, there's a straightforward solution.

Solution: Skipping Events

If you don't need to back up the events or can't alter your user privileges, you can instruct mysqldump to skip events altogether.

For MyISAM Databases:

1. Open your terminal or command prompt.

2. Run the following command:

mysqldump -u username -p --skip-events --databases dbname > dbname_dump.sql

• Replace username with your MySQL username.
• Replace dbname with the name of your database.
• When prompted, enter your MySQL password.

This command will back up your database, excluding events, into a file called dbname_dump.sql.

For InnoDB Databases:

InnoDB databases support transactions, and it's often desirable to use the --single-transaction option for a consistent backup.

1. Open your terminal or command prompt.

2. Run the following command:

mysqldump -u username -p --skip-events --single-transaction --databases dbname > dbname_dump.sql

• Replace username with your MySQL username.
• Replace dbname with the name of your database.
• When prompted, enter your MySQL password.

The --single-transaction option is particularly useful for live systems where locking the database (which happens by default) would interfere with ongoing operations.

Conclusion

Understanding how to navigate around permission issues when performing backups is a handy skill. By using the --skip-events and --single-transaction options, you can effectively back up a MySQL database even as a restricted user. Remember, always ensure you have the necessary permissions to perform backups and consult with your sysadmin when in doubt. Handling data responsibly is paramount, and backups are a critical part of data management.

Resolving Corrupt RPM Database in cPanel

In a cPanel environment, RPM database corruption can cause various package management issues, making it difficult to install, update, or remove software. This guide provides steps to resolve a corrupt RPM database on a cPanel server.
Step 1: Create a Backup Directory
Before making any changes, it's crucial to back up the existing RPM database. This ensures that you can revert to the current state if needed.
Create a Backup Directory:
mkdir /root/old_rpm_dbs/
Step 2: Move the Corrupt Database Files
Move the potentially corrupt RPM database files to the backup directory you just created. This action isolates the corrupt files and prepares the system for database reconstruction.
Move Corrupt Database Files:
mv /var/lib/rpm/__db* /root/old_rpm_dbs/
Step 3: Rebuild the RPM Database
With the corrupt files moved, you can now safely rebuild the RPM database. This process creates a new, clean set of database files.
Rebuild the Database:
rpm --rebuilddb
This command will reconstruct the RPM database based on the installed packages.
Step 4: Verify the Operation
After rebuilding the database, it's good practice to verify that RPM is functioning correctly.
Check for RPM Functionality:
bash
rpm -qa
This command lists all installed packages. If it returns a list without errors, the rebuild was successful.
Step 5: Clean Up (Optional)
If everything is working fine and you're sure the old database files are no longer needed, you can remove the backup directory. However, it's wise to keep these files until you're certain the system is stable.
Remove Backup Directory:
rm -r /root/old_rpm_dbs/
Note: Only do this if you're confident that your system is stable and the backup is no longer needed.
Conclusion
Corrupt RPM databases can disrupt system maintenance and software management. By following these steps, you've learned how to safely rebuild the RPM database in a cPanel environment, restoring functionality and ensuring your system's integrity. Regular system monitoring and backups are crucial to quickly identifying and addressing such issues. If you encounter further problems or suspect database corruption again, repeat these steps and consider investigating the root cause to prevent future occurrences.