Racker Hacker

One of the main reasons people like passive FTP is that it’s easier to get through firewalls with it. However, some users might now know that they need to enable passive FTP, or they may have incapable clients. To get active FTP through firewalls, start by adding these rules:

Allowing established and related connections is generally a good idea:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Inbound connections on port 21 are required:
iptables -A INPUT -p tcp --dport 21 -j ACCEPT

Just to cover our bases, add in a rule to allow established and related traffic leaving port 20 on the client’s machine:
iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT

Now, you have everything you need to allow the connections, but iptables will need to be able to mark and track these connections to allow them to pass properly. That is done with the ip_conntrack_ftp kernel module. To test things out, run this:

modprobe ip_conntrack_ftp

At this point, you should be able to connect without a problem. However, to keep this module loaded whenever iptables is running, you will need to add it to /etc/sysconfig/iptables-config:

IPTABLES_MODULES="ip_conntrack_ftp"

Depending on your situation, it may be handy to redirect e-mails that have a certain subject line before it even reaches a user’s inbox. Let’s say you’re tired of getting e-mails that start with the word “Cialis”. Just follow these steps to redirect those e-mails.

First, enable header checks in /etc/postfix/main.cf:

header_checks = regexp:/etc/postfix/header_checks

Then, create /etc/postfix/header_checks and add the following:

/^Subject: Jobs*/
REDIRECT someotheruser@domain.com

For a lot more information about header checks in postfix, review the documentation here:

http://www.postfix.org/header_checks.5.html

Table corruption in MySQL can often wreak havoc on the auto_increment fields. I’m still unsure why it happens, but if you find a table tries to count from 0 after a table corruption, just find the highest key in the column and add 1 to it (in this example, I’ll say the highest key is 9500).

Just run this one SQL statement on the table:

ALTER TABLE brokentablename AUTO_INCREMENT=9501;

If you run a quick insert and then run SELECT last_insert_id(), the correct key number should be returned (9501 in this case).

If you have postfix installed with OpenSSL support compiled in, you can enable SSL connections by editing two configuration files. First, add the following to /etc/postfix/main.cf:

smtpd_use_tls = yes
#smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/newkey.pem
smtpd_tls_cert_file = /etc/postfix/newcert.pem
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Then, simply uncomment this line in /etc/postfix/master.cf:

smtps     inet  n       -       n       -       -       smtpd

Make sure to keep tabs between the elements in the master.cf file.

In some situations, the system time zone will be different than the one in MySQL, even though MySQL is set to use the system time zone. This normally means that a user has changed the system time zone, but they haven’t started MySQL to cause it to change as well.

$ date
Sun Jul  1 11:32:56 CDT 2007
mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | PDT    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

If you find yourself in this situation, just restart MySQL and the situation should be fixed:

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CDT    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

If this situation pops up in Plesk, it means that a user has changed their MySQL password outside of Plesk. The password in Plesk’s own database does not match, so the auto-creation of the phpMyAdmin settings fails. You’ll end up seeing this after clicking “DB WebAdmin”:

MySQL said: Non-static method PMA_Config::isHttps() should not be called statically

The funny thing is that MySQL doesn’t actually say this. It’s a PHP error. To correct the problem, you can manually change the password within Plesk’s database, or you can follow an easier method:

Click Databases
Click Database Users
Click the user that has a password change
In the password fields, enter the new password that they’re using with MySQL

This will force Plesk to change its password in its own database, and it will run the query to change the password in MySQL (but since it’s the same password, no change will be made).