If you are switching out static content that have gotten cached in nginx, the head of the cached files usually stores the file path that can be greped for and the file removed. One you hit the url again, it will recreate the new cached file at the same location.

Below are one liners to clean out all comment and blank lines with grep and sed, usually in config files.

or

Nginx is a fast and efficient web server. It can be configured to serve out files or be a reverse proxy depending on your application. What makes this web server different from Apache, Lighttpd or thttpd is the overall efficiency of the daemon, the number of configuration options and how easy it is to setup....

If you notice that /etc/shadow file password is using DES encryption, MD5 encryption can be enabled via:

If authconfig is not present edit, "/etc/pam.d/system-auth" and add "md5 shadow" to line starting with "password sufficient pam_unix.so" so it looks like below:

Below is how I have migrated mail server with minimum downtime and routing mail to the new server via mailertable, if IP is still pointing to the old server and has not resolved for some ISPs.

• 48 hours prior to migration, set the TTL value for the mail server DNS A record to a short time like 15 minutes.
  
• Prepare for the migration, rsycing the mail spool folder and the user home mail folders.
  
  rsync --progress -a -e "ssh -i /root/.ssh/key -p 22" old.mailserver:/var/spool/mail/ /var/spool/mail/
rsync --progress -a -e "ssh -i /root/.ssh/key -p 22" old.mailserver:/var/www/web1/mail/ /var/www/web1/mail/
rsync --progress -a -e "ssh -i /root/.ssh/key -p 22" --exclude='*/bak' --exclude='*/web' old.mailserver:/var/www/web1/user/ /var/www/web1/user/
• At the time of migration, firewall incoming port 25 on the old mail server and update the DNS A record to point to the new server.
  
• Run rsync the final time.
  
• Setup Sendmail with mailertable to relay mail coming in to the old server over to the new mail server. This is a similar setup for secondary mail servers.
  
• Add "FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl" to "/etc/mail/sendmail.mc" if it does not already exist.
  
• Create "/etc/mail/mailertable" file with contents of the routing table:
  
  domain.tld esmtp:[xxx.xxx.xxx.xxx]
  
  The square brackets skips checking MX records, so IP can be used instead.
• Remove domain name from "/etc/mail/local-host-names" so mails do not get delivered locally.
  
• Edit "/etc/mail/access" to relay mail for the domain.
  
  TO:domain.tld RELAY
• Rebuild the access and mailertable databases.
  
  cd /etc/mail
makemap hash access.db < access
makemap hash mailertable.db < mailertable
• Restart sendmail and open up the firewall.
  
• Test by telneting to port 25 on the old servers' IP and sending email. This should get relayed over to the new server.
  
• Use a new subdomain and redirect existing webmail url to the new server.

Synaptic is a graphical user interface (GUI) for managing software packages on Debian-based distributions. If you are using Debian or Ubuntu you will easily find Synaptic in the System Tools menu or in the Administration menu.This tutorial will explain how to install,remove and upgrade packages using Synaptic in ubuntu.

One of the most commonly seen questions when dealing with firewalls and other Internet connectivity issues is the difference between active and passive FTP and how best to support either or both of them. Hopefully the following text will help to clear up some of the confusion over how to support FTP in a firewalled environment...

The output of SQL Plus can be a annoying a little bit. Here are some techniques that show how to enhance the readability of SQL Plus output...

How do I audit file events such as read / write etc? How can I use audit to see who changed a file in Linux?

The answer is to use 2.6 kernel’s audit system. Modern Linux kernel (2.6.x) comes with auditd daemon. It’s responsible for writing audit records to the disk. During startup, the rules in /etc/audit.rules are read by this daemon. You can open /etc/audit.rules file and make changes such as setup audit file log location and other option. The default file is good enough to get started with auditd.

If you've just made any changes to the nameservers, you can verify if this has propagated at the root level.

Check root servers for the corresponding tld first. So for .com domains:

The output is as below:

Now query the root servers for the corresponding domain:

The additional section from the result with the IP address show the glue records.