Thursday, June 20, 2013

Stop Ubuntu / Debian Linux From Deleting /tmp Files on Boot

Category: — SkyHi @ Thursday, June 20, 2013
Q. I know /tmp as it named is a temporary dircory, Debian policy is to clean /tmp at boot. However, I'd like to configure my Ubuntu Server to stop deleting files from /tmp on boot due to custom configuration issue. How do I configure behavior of boot scripts to stop deleting files on boot?

A. Users should not store files in /tmp, use /home or other partition, if you would like to keep the files. The behavior of boot scripts is controlled via a special configuration file called /etc/default/rcS. Open this file and modify TMPTIME variable.
On boot the files in /tmp will be deleted if their modification time is more than TMPTIME days ago. A value of 0 means that files are removed regardless of age. If you don't want the system to clean /tmp then set TMPTIME to a negative value(-1) or to the word infinite.

Configuration /etc/default/rcS

Open /etc/default/rcS file, enter:
$ sudo vi /etc/default/rcS
Set TMPTIME to 60 so that files in /tmp will deleted if their modification time is more than 60 days ago.
TMPTIME=60
Close and save the file. This configuration is used by /etc/init.d/bootclean script on boot to clean /tmp and other directories under all Debian based Linux distros.

A note about RHEL / CentOS / Fedora / Redhat Linux

Redhat and friends use /etc/cron.daily/tmpwatch cron job to clean files which haven’t been accessed for a period of time from /tmp. The default is 720 hours. If the file has not been accessed for 720 hours, the file is removed from /tmp. You can modify this script as per your requirements:
# cp /etc/cron.daily/tmpwatch /etc/cron.daily/tmpwatch.bak
# vi /etc/cron.daily/tmpwatch

REFERENCES
http://www.cyberciti.biz/faq/debian-ubuntu-removes-files-at-boot-time/

Tuesday, June 11, 2013

IP_CONNTRACK: TABLE FULL, DROPPING PACKET

Category: , — SkyHi @ Tuesday, June 11, 2013
Last week, I found myself with a server under low load, but it couldn’t make or receive network connections. When I ran dmesg, I found the following line repeating over and over:
ip_conntrack: table full, dropping packet
I’d seen this message before, but I headed over to Red Hat’s site for more details. It turns out that the server was running iptables, but it was under a very heavy load and also handling a high volume of network connections. Generally, the ip_conntrack_max is set to the total MB of RAM installed multiplied by 16. However, this server had 4GB of RAM, but ip_conntrack_max was set to 65536:
# cat /proc/sys/net/ipv4/ip_conntrack_max
65536
I logged into another server with 1GB of RAM (RHES 5, 32-bit) and another with 2GB of RAM (RHES 4, 64-bit), and both had ip_conntrack_max set to 65536. I’m not sure if this is a known Red Hat issue, or if it’s just set to a standard value out of the box.
If you want to check your server’s current tracked connections, just run the following:
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
If you want to adjust it (as I did), just run the following as root:
# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max

REFERENCES

Thursday, May 23, 2013

Remount using fstab entries

Category: — SkyHi @ Thursday, May 23, 2013

7.1.2. Remounting the File Systems

After adding the usrquota and/or grpquota options, remount each file system whose fstab entry has been modified. If the file system is not in use by any process, use one of the following methods:
  • Issue the umount command followed by the mount command to remount the file system.(See the manpage for both umount and mount for the specific syntax for mounting and unmounting various filesystem types.)
  • Issue the mount -o remount  command (where  is the name of the file system) to remount the file system. For example, to remount the /home file system, the command to issue is mount -o remount /home.
If the file system is currently in use, the easiest method for remounting the file system is to reboot the system.


REFERENCES

Monday, April 29, 2013

Error : ” child pid exit signal File size limit exceeded (25) in Apache ” Resolution

Category: — SkyHi @ Monday, April 29, 2013

Many times if you find apache processes dying in the top process list or apache failing to start completely then one of the reasons could be a log file larger than 2Gb , which is indicated by the below error in the apache error logs :

child pid XXXX exit signal File size limit exceeded (25)
where XXXX is process id for the process which is failing and generating the error in the error log.
To fix this you will need to locate the log file which has grown to or above 2Gb size and either empty it or make a tar , rename and create a new log file. It can be access_log , error_log itself, the suphp_log , suexec_log etc.
For cPanel serves you should set the log rotation from following link in WHM to avoid this :
WHM >> Service Configuration >> Apache Configuration >> Log Rotation
For finding files greater then 2Gb below commands can be helpful :

This will print the top ten files with respect to size in the current directory
# find `pwd` -xdev -type f -ls | sort -k7nr | head

This will print any files greater than 2Gb
# ls -l | awk '{ if ( $5 > 2147483648 ) print $9 "\t" $5 }'

This will show files greater than 2Gb using simple find command
# find / -size +2G
Note : Depending on the version of find command on your server you may need to use different value, like in Mbs or Kbs in your find command.

REFERENCES

Monday, April 22, 2013

Error ID: 0x800CCC0F

Category: — SkyHi @ Monday, April 22, 2013

Some of the possibilities for this error are as follows :


1. Make sure your e-mail settings are correct: Mail Server, Username, and Password.

2. Clear messages in the outbox folder

3. Delete large emails, if any, in webmail.

4. Adjust mail server timeouts.

5. Your antivirus program has e-mail protection enabled, which checks the mail as it comes in from your Post Office Protocol (POP) server. Temporarily disable the antivirus e-mail protection utility and check.

6. Create a new profile to check if it's a profile issue.

Monday, April 15, 2013

What is a Glue Record?

Category: — SkyHi @ Monday, April 15, 2013

Glue Records

This article offers a definition of a Glue Record, a description of why a Glue Record is need and how they are resolved through DNS, and how to create a Glue Record through the CloudAccess.net Client Area.

What is a Glue Record?

Why are Glue Records needed?

How to create a Glue Record

What is a Glue Record?

A Glue Record is the IP Address of a name server at a domain name registry. Glue Records are fundamental parts of DNS records because they help to resove DNS servers at a core level. If you would like to change the name servers for a site, you ll have to provide the Glue Records for the new name serves. Without them, a domain name will not work because anyone requiring the DNS information will be stuck in a loop. There is a cyclic dependency of circular referencing. Circular references exist where the name servers for a domain can t be resolved without resolving the domain they re responsible for. Glue Records are additional A records that allow the DNS client to locate name servers. 

When are Glue Records needed?

For example, let s say your domain (yourdomain.com) is using ns1.nameserver.com and ns2.nameserver.com as name servers, but gridfast.net also uses ns1.nameserver.com and ns2.nameserver.com as name servers. This is how the cyclic dependency is created. To break the cycle, DNS systems use Glue Records. 
You can also understand Glue Records by understanding A Records. An A record (an A address) is a DNS record that can be used to point your domain name and host names to a static IP address. For example, the A record for gridfast.net includes ns1.gridfast.net and ns2.gridfast.net and their IP addresses. These servers can be reached directly without any further resolution. For a domain name like CloudAccess.net, however, the root DNS servers pass the ns1.gridfast.net and ns2.gridfast.net nameservers, and a further chain of resolution is needed to resolve the DNS. This is when a Glue Record is needed.


REFERENCES
http://www.cloudaccess.net/infrastructure-networking/66-servers-dns/318-glue-records.html

MySQL 4.1+ using old authentication

Category: — SkyHi @ Monday, April 15, 2013

When I was working with XAMPP in Ubuntu and asked write PHP script to connect to remote MySQL server which is using PASSWORD hash function to save the password for user, and I found following error.

Warning: mysql_connect() [function.mysql-connect]: Premature end of data (mysqlnd_wireprotocol.c:554) in path/to/the/file/where/connection/script/is/written/

Warning: mysql_connect() [function.mysql-connect]: OK packet 1 bytes shorter than expected in path/to/the/file/where/connection/script/is/written/

Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file in path/to/the/file/where/connection/script/is/written/

As you will see, the core issue here is that MySQL can have passwords with hashes stored in the old 16-character format, which is not supported by PHP 5.3′s new mysqlnd library.
Since I couldn’t find a good solution with a quick Google, here is how I solved this without having to downgrade PHP or MySQL (as some of the solutions suggested):

1. Change MySQL to NOT to use old_passwords
It seems that even MySQL 5.x versions still default to the old password hashes. You need to change this in “my.cnf” (e.g. /etc/my.cnf): remove or comment out the line that says
old_passwords = 1
Restart MySQL. If you don’t, MySQL will keep using the old password format, which will mean that you cannot upgrade the passwords using the builtin PASSWORD() hashing function. You can test this by running:
 
mysql> SELECT Length(PASSWORD('xyz'));
+-------------------------+
| Length(PASSWORD('xyz')) |
+-------------------------+
|                      16 |
+-------------------------+
1 row in set (0.00 sec)
The old password hashes are 16 characters, the new ones are 41 characters.
2. Change the format of all the passwords in the database to the new format
Connect to the database, and run the following query:
mysql> SELECT user,  Length(`Password`) FROM `mysql`.`user`;

This will show you which passwords are in the old format, ex:
+----------+--------------------+
| user     | Length(`Password`) |
+----------+--------------------+
| root     |                 41 |
| root     |                 16 |
| user2    |                 16 |
| user2    |                 16 |
+----------+--------------------+
Notice here that each user can have multiple rows (one for each different host specification).
To update the password for each user, run the following:
UPDATE mysql.user SET Password = PASSWORD('password') WHERE user = 'username';
Finally, flush privileges:
FLUSH PRIVILEGES;


REFERENCE
http://lampsailesh.blogspot.com/2011_05_01_archive.html#5294498109303285481
Subscribe to: Posts (Atom)