How to Move MySQL Datadir to an alternate location

In this guide, we'll walk through the process of changing the MySQL data directory to a new location to free up space on the /var partition. This is particularly useful when the /var partition is running low on space, causing MySQL to fail or lose data. Follow these steps carefully to ensure a smooth transition.

Step 1: Backup the MySQL Databases

First, it's crucial to create a backup of all MySQL databases to ensure data security. Execute the following command to dump all databases into a single file and compress it:

mysqldump --add-drop-table --all-databases | gzip > /home/alldatabases.sql.gz

Step 2: Stop the MySQL Server

Before moving the data directory, stop the MySQL server using the following command:

/etc/init.d/mysql stop

Step 3: Move the Data Directory

Navigate to the current MySQL data directory (/var/lib) and move it to the new location (/home/mysql) using the following commands:

cd /var/lib mv mysql /home/mysql

Step 4: Create Symbolic Link

Create a symbolic link from the original data directory location to the new location to ensure compatibility with MySQL configurations:

ln -s /home/mysql mysql

Step 5: Set Ownership

Ensure that the MySQL user owns the new data directory by executing the following command:

chown -R mysql:mysql /home/mysql

Step 6: Start MySQL Server

Start the MySQL server using the following command:

/etc/init.d/mysql start

Step 7: Verify MySQL Status

Check the status of the MySQL server to ensure it's running without any issues:

ps aux | grep mysql

Conclusion

By following these steps, you've successfully moved the MySQL data directory from the /var partition to a new location (/home/mysql), thereby freeing up space on the /var partition. This ensures smooth operation of MySQL and prevents data loss or service failures due to insufficient disk space. Always remember to back up your databases before making significant changes to ensure data integrity. If you encounter any issues, feel free to seek assistance from a qualified administrator.

exim dead but subsys locked

Exim, the widely-used mail transfer agent (MTA), can sometimes cause issues on servers, especially when it needs to be temporarily disabled or restarted. One common error encountered is "exim dead but subsys locked." Here's a simple guide on how to disable Exim and resolve this error quickly.

1. Stop the Exim Service

To stop the Exim service, use one of the following commands based on your system:

/etc/init.d/exim stop

or

service exim stop

2. Create an Empty File

Next, create an empty file named "eximdisable" under the "/etc" directory using the following command:

touch /etc/eximdisable

Now, when you attempt to restart or start the Exim service, you'll encounter the following error:

/etc/init.d/exim status exim dead but subsys locked

This indicates that the Exim service remains stopped, and "chkservd" cannot start it.

3. Fix the Error

To resolve the "exim dead but subsys locked" error, simply remove the "eximdisable" file using the following command:

rm -rf /etc/eximdisable

Once the file is removed, the Exim service can be started or restarted without encountering the error.

Conclusion

Disabling Exim temporarily and fixing the "exim dead but subsys locked" error is a straightforward process. By following these steps, you can manage Exim effectively on your server and troubleshoot common issues with ease. If you encounter any further difficulties, feel free to reach out for assistance, and we'll be here to help you promptly.

Simplifying PostgreSQL Authentication: A Guide to Editing pg_hba.conf

Managing authentication in PostgreSQL can sometimes be cumbersome, especially when dealing with frequent user switches. However, there's a straightforward solution to streamline this process by editing the pg_hba.conf file. Let's explore how to modify this file to enable passwordless authentication for specific users, such as the PostgreSQL superuser, and then revert the changes after setting a new password.

Locating the pg_hba.conf File

Before making any changes, it's crucial to locate the pg_hba.conf file, which contains authentication rules for PostgreSQL connections. The file path may vary depending on the distribution:

• CentOS: /var/lib/pgsql/data/pg_hba.conf
• Ubuntu: /etc/postgresql/9.1/main/pg_hba.conf

Editing pg_hba.conf for Trust Authentication

Once the file is located, open it using a text editor and locate the relevant authentication rule. For example, to allow passwordless authentication for the PostgreSQL superuser (postgres), find the line similar to:

# Database administrative login by Unix 
domain socket local all postgres peer
 





Change the authentication method from "peer" to "trust" as follows:

# Database administrative login by Unix

domain socket local all postgres trust

Changing PostgreSQL User Password

After modifying pg_hba.conf, save the changes and exit the text editor. Now, it's time to change the password for the PostgreSQL superuser. Open a terminal and execute the following command:

psql -U postgres ALTER USER postgres WITH PASSWORD 'secure-password';

Replace 'secure-password' with your desired password. This command updates the password for the postgres user within the PostgreSQL database.

Reverting Changes and Reloading PostgreSQL Service

Once the password is updated successfully, revert the changes made to pg_hba.conf to enhance security. Restore the authentication method back to its original state by modifying the line to:

# Database administrative login by Unix 

domain socket local all postgres peer

Save the changes and exit the text editor. Finally, reload the PostgreSQL service to apply the modifications:

sudo service postgresql reload

Conclusion

By editing the pg_hba.conf file, PostgreSQL authentication can be simplified, allowing passwordless authentication for specific users when needed. However, it's essential to revert the changes promptly after updating passwords to maintain security standards. With this guide, managing PostgreSQL authentication becomes more accessible and efficient for system administrators.