When login to WHM Reseller redirected to hostname

Finally I found the solution in http://www.webhostingtalk.com/showthread.php?t=628673

 

Mass Removal of error_log Files

It’s always a good idea to back something up before you begin working on an improvement to it or upgrading it to a new version. For example, before I upgrade my WordPress installs I always back up their files and databases.

This seems simple enough but every time I back up any of my PHP projects (WordPress or any other) I seem to run into the same problem: error_log files.

error_log files are the product of Apache’s error logging functionality. Whenever you go to a site running an Apache webserver and get a PHP error the error is put in a file called error_log that is stored in the directory in which the file that throws the error resides. For example, if you get a PHP error when trying to access http://www.domain.com/index.php the error will be logged in an error_log file in the root of the site. However if you get an error when trying to visit http://www.domain.com/test/index.php the will be logged to error_log in the /test subdirectory.

The problem is that over time these files can grow very large and be spread through many directories all over your website. So when you try to back up numerous directories you can end up with a larger than necessary backup file filled with many error_log files (some of which can grow quite large themselves). And since these files do not serve any other need but to log errors it seems useless to have them in your backup.

The good news is that error_log files can be removed at any time with no repercussions to the functionality of other files within their directories. But the removal of these files can prove to be a difficult since they can be in any directory. Who wants to manually look in every directory of a WordPress install to find and delete all the instances of error_log files?

Luckily I chanced upon a solution by Lester “GaMerZ” Chan. GaMerZ wrote a PHP script called “GaMerZ error_log Cleaner”. When it’s page is accessed “GaMerZ error_log Cleaner” crawls your website for error_log files and removes them all automatically. “GaMerZ error_log Cleaner” can be downloaded here.

As an added tip I’d suggest changing the name of the error_log.php file for security purposes lest it become an attack vector. If you do this then be sure to change the $this_file variable at the top of the script to match the new filename.

URL download: http://lesterchan.net/portfolio/programming/php/#gec
src: http://nothing.golddave.com/2011/01/04/mass-removal-of-error_log-files/

 

make the ‘A’ with inline assembly

#include <conio.h>
#include <dos.h>
#include <stdlib.h>

#define VIDEO_INT 0x10

int main(void)
{

clrscr();
asm mov ah, 0x09;
asm mov al, 0x41;
asm mov bh, 0x00;
asm mov bl, 0x07;
asm mov ch, 0x00;
asm mov cl, 0x01;
asm int VIDEO_INT;

getch();
return EXIT_SUCCESS;
}

 

makin ‘A’ with int86

#include
#include
#include

#define VIDEO_INT 0x10

int main(void)
{
union REGS in, out;

in.h.ah = 0x09;
in.h.al = 0x41;
in.h.bh = 0x00;
in.h.bl = 0x07;
in.h.ch = 0x00;
in.h.cl = 0x01;

clrscr();
int86(VIDEO_INT ,&in, &out);
getch();
return EXIT_SUCCESS;
}

 

page.tpl.php

Line 64:

<script type=”text/javascript”>
var fo = new FlashObject(“<?php print base_path().path_to_theme() ?>/flash/header4_fv8.swf?xmlUrl=<?php print base_path().path_to_theme() ?>/flash/”, “mymovie”, “922”, “419”, “8”, “”);
fo.addParam(“quality”, “high”);
fo.addParam(“wmode”, “transparent”);
fo.addParam(“scale”, “noscale”);
fo.write(“flashcontent”);
</script>

Line 61

 

SSH

Generating public/private dsa key pair.

Your identification has been saved in /root/.ssh/root.

Your public key has been saved in /root/.ssh/root.pub.

The key fingerprint is:

6b:0a:08:1f:4a:b6:7a:a4:04:d9:69:5a:e3:0b:53:65 root@2637.xxx.com

SSH Password Authorization Tweak
Password Auth has been enabled!

SSH Server…

Waiting for sshd to restart……………finished.

sshd (/usr/sbin/sshd) running as root with PID 23742

sshd started ok

…Done

 

Display PostgreSQL/PgSQL version

Display the PostgreSQL version number (and other information like compiler version used to build PgSQL) issue the following SQL statement from within psql:

SELECT version();

To quickly determine just the PostgreSQL version number, run this command from the OS command line:

psql –version

root@nikko[~]# psql –version
psql (PostgreSQL) 8.1.23
contains support for command-line editing

src: http://www.tech-recipes.com/rx/282/display-postgresqlpgsql-version/

 

HOW TO: Speed Up DNS Propagation after Changing Host

One of the things that you would encounter once you changed hosting is for DNS propagation to resolve quickly in order for your website to be back online. At some point, you may want to do something to make it a little faster but there are certain factors that hinder it from occurring.

Before you can appreciate how DNS propagation works, you must first understand that DNS (stands for Domain Name Server) is something that your web hosting provider creates particularly a Master DNS record for your domain. Your domain registrar (the company where you paid to own your domain) then points to your web host’s DNS servers and once the update is completed, outside sources can view your site online the moment they find your site’s corresponding IP address via your web host as the master authority of your domain.

Web hosting environments actually set TTL (Tweaking Time-To-Live) values on their end so as not to overuse the servers from too many requests. Your local ISP (Internet Server Provider) also caches their DNS records in order for them to render webpage requests locally than looking them up online each time thus resulting for a faster web surfing experience.

This caching system however is the reason why your website doesn’t immediately show up online after any hosting transfer. Most of the time, ISP’s cached DNS records are only updated after every few days that’s why you would always have to expect that when you transfer hosting, you’ll be advised that it will take 48-72 hours before you can view your site online.

The time is takes for your ISP’s DNS server cache to update is called propagation. Once it resolves, you can already view your website online.

In my case, it didn’t actually take an entire day before I was able to see my site back online not even longer than 12 hours!

In case you will encounter the same scenario, here’s how you do it:

1. In windows, click Start > Run and type in cmd (a command window will open).

2. Type in ipconfig /flushdns then press Return/Enter.

If the above solution doesn’t work, you may use a frequently updating DNS service like OpenDNS, a fast and intelligent DNS service for free.

To give you a faster result than your ISP server, you can set up OpenDNS using the following servers:

Preferred DNS Server: 208.67.222.222
Alternate DNS Server: 208.67.220.220

These DNS servers can easily be setup in your computer’s TCP/IP settings or router. This step works most of the time like it did for me because this resolves website inaccessibility due to DNS propagation time lag (see XP setup screenshot below).

Here’s how you set it up on WindowsXP:

1. Press Start> click Control Panel> choose Network and Internet Connections> then click Network Connections> choose LAN connection, right-click then choose Properties.

2. Double click Internet Protocol (TCP/IP) then fill out “Use the following DNS server addresses” with the ones taken from OpenDNS then save your settings.

For more instructions on how to set up OpenDNS on different routers and OS, visit this link.http://www.opendns.com/

 

How to Speed Up DNS Propagation

When migrating web host to a different hosting service’s server or modifying the server’s IP address, the most important consideration to guarantee to retain availability of the websites hosted on the server, minimize the downtime of the web sites, avoid strange troubles such as emails get delivered to either server randomly, or surfing at old server, is how fast DNS (Domain Name System) will be able to read or resolve hostname or domain name into your new IP address, rather than the old IP address. Unluckily, webmasters have limited ability to control or override the DNS propagation process. However, there are still a few tips, tricks and workarounds that guarantee DNS cache will refresh the new IP addresses as soon as possible.

DNS acts in such as aside that when a request for IP address received by DNS resolver, it will then query the root hosts to find the authorized server with detailed knowledge of the specific domain name. If a valid IP address for the domain is returned by the authoritative server, the DNS resolver will cache the DNS propagation for a given time period called TTL (Time To Live) after a successful reply, in what called DNS caching in order to reduce the load on particular DNS server. DNS caching provides resolution of domain name to IP to happen locally using the cached information rather than querying the remote server for subsequent requests, till the TTL duration expires.

The Time-To-Live (TTL) timer is the trick to guarantee that the DNS cache expires promptly and all of the time stays fresh. TTL is defined by domain administrator in the authoritative DNS server for the zone wherever data originates, and its values tell DNS caching resolvers to expire and dispose the DNS records after TTL seconds. Lowering the TTL value will enable fast expiration and refreshing of DNS records, making the new records to propagate faster across the world. Still, the trick demands the name resolvers comply the RFC standards, which most do. Alongside, you must have full control to change the name server authoritative for your domains.

The tweaking of TTL in DNS records must be done a couple of days before it’s about to change (date of server moving or IP change) to assure that all DNS caching resolvers picks up the fresh TTL value and expires the old longer value. The trick will cut down the TTL in anticipation of the alteration to minimize inconsistency during the change, according to RCF 1034.

TTL is defined by Minimum field in SOA (Start of Authority) type as default TTL, or separately at each record as TTL. RCF 1912 describes the Minimum field in details as below:

Minimum: The default TTL (time-to-live) for resource records (RR) — how long data will remain in other nameservers’ cache. ([RFC 1035] defines this to be the minimum value, but servers seem to always implement this as the default value) This is by far the most important timer. Set this as large as is comfortable given how often you update your nameserver. If you plan to make major changes, it’s a good idea to turn this value down temporarily beforehand. Then wait the previous minimum value, make your changes, verify their correctness, and turn this value back up. 1-5 days are typical values. Remember this value can be overridden on individual resource records.

If you are using a web-based or GUI to manage your domain’s DNS records, and then log on to the system, and edit the SOA records. Inside you’ll see a field named Minimum, change the value to as low as possible (in seconds), such as 300 for timeout every 5 minutes. Then change the TTL for all of the A, MX, CNAME, TXT, SOA, PTR and other records, if applicable.

If you are using cPanel WebHost Manager (WHM), log-in and select Edit DNS Zone under DNS Functions section. Choose the applicable zone (domain name). You’ll be given with a list of records. Alter the minimum ttl in SOA, and TTL column of A, MX, CNAME and other records defined.

For those manually configure the authoritative nameserver for a domain zone using BIND, modification has to be done in the zone file. For example, so domain zone example.com, you will see the following resource records in the zone file:
; zone ‘example.com’
$TTL 14400

@ IN SOA ns1.example.com. host.example.com. (
2007080501 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
604800 ; Expire 1 week
86400 ); Minimum 24 hours

@ NS ns1.example.com.
@ NS ns2.example.com.

@ A 192.168.0.1
@ MX 10 mail.example.com.

; nameservers
ns1 A 192.168.0.11
ns2 A 192.168.0.12
; mail servers
mail A 192.168.0.10
; web server
www CNAME example.com.

Now modify the $TTL 14400 with the value you wish (in seconds), such as 300 (5 minutes). This value defines the default TTL of every existing records, and by lowering this value to 300 (for example, you can choose your won value), caching server will be hold this records for more than 5 minutes before querying the authoritative name server which will be the 1st to reflect the new IP address when change later on again. Some other value that you should modify is minimum TTL, the last line of SOA type (remarked as minimum 24 hours).

Afterwards, your DNS zone file will probably looks like this:
; zone ‘example.com’
$TTL 300

@ IN SOA ns1.example.com. host.example.com. (
2007080501 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
604800 ; Expire 1 week
300 ); Minimum 24 hours

@ NS ns1.example.com.
@ NS ns2.example.com.

@ A 192.168.0.1
@ MX 10 mail.example.com.

; nameservers
ns1 A 192.168.0.11
ns2 A 192.168.0.12
; mail servers
mail A 192.168.0.10
; web server
www CNAME example.com.

Restart the DNS service. The fresh TTL value will propagate to other DNS nameserver. This process normally takes 48 hours to 72 hours (hence the need to reduce TTL to try to make it faster when altering the critical A and MX records). After waiting for a few days, move your websites to new server or modify the IP address, then update the DNS records to point to the new server or IP.

Once done, you can now return back the TTL values to reduce the load on your DNS server.

 

setting.php

$db_url = ‘mysql://kotakomn_drpl1:e3S5kUUk6oUj@localhost/kotakomn_drpl1’;