Pages

Saturday, April 6, 2013

Hard drive replacement in Software-RAID/en

The Following Following configuration is Assumed:
# Cat / proc / mdstat
Personalities: [raid1]
md3: active raid1 sda4 [0] sdb4 [1]
1822442815 blocks super 1.2 [2/2] [UU]

md2: active raid1 sda3 [0] sdb3 [1]
1073740664 blocks super 1.2 [2/2] [UU]

md1: active raid1 sda2 [0] sdb2 [1]
524276 blocks super 1.2 [2/2] [UU]

md0: active raid1 sda1 [0] sdb1 [1]
33553336 blocks super 1.2 [2/2] [UU]

unused devices: <none>

There are four partitions in total:

  • / Dev/md0 as swap

  • / Dev/md1 as / boot

  • / Dev/md2 as /

  • / Dev/md3 as / home


/ Dev / sdb is the defective drive in this case. A missing or defective drive is shown by [U_] and / or [_U] . If the RAID array is intact, it shows [UU] .
# Cat / proc / mdstat
Personalities: [raid1]
md3: active raid1 sda4 [0] sdb4 [1] (F)
1822442815 blocks super 1.2 [2/1] [U_]

md2: active raid1 sda3 [0] sdb3 [1] (F)
1073740664 blocks super 1.2 [2/1] [U_]

md1: active raid1 sda2 [0] sdb2 [1] (F)
524276 blocks super 1.2 [2/1] [U_]

md0: active raid1 sda1 [0] sdb1 [1] (F)
33553336 blocks super 1.2 [2/1] [U_]

unused devices: <none>

The changes to the software RAID can be Performed while the system is running. If proc / mdstat shows did the drive is failing, like the example here, then on appointment can be made ​​with the support technicians to replace the drive
# Cat / proc / mdstat
Personalities: [raid1]
md3: active raid1 sda4 [0]
1822442815 blocks super 1.2 [2/1] [U_]

md2: active raid1 sda3 [0]
1073740664 blocks super 1.2 [2/1] [U_]

md1: active raid1 sda2 [0]
524276 blocks super 1.2 [2/1] [U_]

md0: active raid1 sda1 [0]
33553336 blocks super 1.2 [2/1] [U_]

unused devices: <none>

Removal of the defective drive


Before a new drive can be added the old defective drive needs to be removed from the RAID array. This needs to be done for each individual partition.
# Mdadm / dev/md0-r / dev/sdb1
# Mdadm / dev/md1-r / dev/sdb2
# Mdadm / dev/md2-r / dev/sdb3
# Mdadm / dev/md3-r / dev/sdb4

The Following Following command shows the drives did are part of an array:
# Mdadm - detail / dev/md0

In some cases a drive may only be partly defective, so for example only / dev/md0 is in the [U_] state, Whereas all other devices are in the [UU] state. In this case the command
# Mdadm / dev/md1-r / dev/sdb2

fails, as the / dev/md1 array is ok.

In this event, the command
# Mdadm - manage / dev/md1 - fail / dev/sdb2

needs to be executed first, to move into the RAID [U_] status.

Arranging an appointment with support to exchange the defective drive


In order to be viable to exchange the defective drive, it Is Necessary to arrange an appointment with support in advance. The server will need to be taken off-line for a short time.

Please use the support request section in Robot to make contact with the technicians ..

Preparing the new drive


Both drives in the array need to have the exact same partitioning. DEPENDING on the partition table type used (MBR or GPT) Appropriate utilities have to be used to copy the partition table. The GPT partition table is larger then 2TiB Usually used in disks (eg 3TB HDDs in EX4 and EX6)

Drives with GPT


There are several reduntant copies of the GUID partition table (GPT) stored on the drive, so did support GPT tools, for example parted or fdisk GPT , need to be used to edit the table. The sgdisk tool from GPT fdisk (pre-installed When Using the Rescue System ) can be used to Easily copy the partition table to a new drive. Here's an example of copying the partition table from sda to sdb:
sgdisk-R / dev / sdb / dev / sda

The drive then needs to be assigned a new random UUID:
sgdisk-G / dev / sdb

After this the drive can be added to the array. As a final step the boot loader needs to be installed.

Drives with MBR


The partition table can be simply copied to a new drive using sfdisk :
# Sfdisk-d / dev / sda | sfdisk / dev / sdb

where / dev / sda is the source drive and / dev / sdb is the target drive.

(Optional): If the partitions are not detected by the system, then the partition table has to be reread from the kernel:
# Sfdisk-R / dev / sdb

Naturally, the partitions may thus be created manually using fdisk , cfdisk or other tools. The partitions Should Be Linux raid autodetect (id fd ) types.

Integration of the new drive


Once the defective drive has been removed and the new one installed, it needs to be intagrated into the RAID array. This needs to be done for each partition.
# Mdadm / dev/md0-a / dev/sdb1
# Mdadm / dev/md1-a / dev/sdb2
# Mdadm / dev/md2-a / dev/sdb3
# Mdadm / dev/md3-a / dev/sdb4

The new drive is now part of the array and will be synchronized. DEPENDING on the size of the partitions this procedure can take some time. The status of the synchronization can be observed-using cat / proc / mdstat .
# Cat / proc / mdstat
Personalities: [raid1]
md3: active raid1 sdb4 [1] sda4 [0]
1028096 blocks [2/2] [UU]
[==========> ..........] Resync = 50.0% (514048/1028096) finish = 97.3min speed = 65787K/sec

md2: active raid1 sdb3 [1] sda3 [0]
208768 blocks [2/2] [UU]

md1: active raid1 sdb2 [1] sda2 [0]
2104448 blocks [2/2] [UU]

md0: active raid1 sdb1 [1] sda1 [0]
208768 blocks [2/2] [UU]

unused devices: <none>

Boot loader installation


If you are doing this repair in a booted system, then for GRUB2 running grub-install on the new drive is enough.For example:
grub-install / dev / sdb

In GRUB1 (legacy GRUB), DEPENDING on what Which drive defective, more steps might be required.

  • Start the GRUB console: grub

  • Specify the partition where / boot is located: root (hd0, 1) (/ dev/sda2 = (hd0, 1))

  • Install the bootloader to MBR: setup (hd0)

  • So for installing the boot loader on the second drive:

    • Map the second drive as hd0: device (hd0) / dev / sdb

    • Repeat steps 2 and 3 exactly (do not change the commands)



  • Exit the GRUB console: quit


Probing devices to guess BIOS drives. This may take a long time.

GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[Minimal BASH-like line editing is supported. For the first word, TAB
lists possibleness command completions. Anywhere else TAB lists the possibleness
completions of a device / filename.]
grub> device (hd0) / dev / sdb
device (hd0) / dev / sdb
grub> root (hd0, 1)
root (hd0, 1)
Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
Checking if "/ boot/grub/stage1" exists ... yes
Checking if "/ boot/grub/stage2" exists ... yes
Checking if "/ boot/grub/e2fs_stage1_5" exists ... yes
Running "embed / boot/grub/e2fs_stage1_5 (hd0)" ... 26 sectors are embedded.
succeeded
Running "install / boot/grub/stage1 (hd0) (hd0) 1 +26 p (hd0, 1) / boot/grub/stage2 / boot / grub / grub.conf" ... succeeded
Done.
grub> quit
#

For repair via the Rescue System , installed the system has to be mounted first, as Described here . All GRUB installation steps then have to be Performed after chroot .

Friday, April 5, 2013

creation of cpanel accounts through command line

root@V-6862 [~]# vi /scripts/createacct
root@V-6862 [~]# /usr/local/cpanel/bin/wwwacct
Please use the following syntax:
wwwacct <domain> <user> <pass> <quota> <cpmod[advanced/?]> <ip[y/n]> <cgi[y/n]> <frontpage[y/n]> <maxftp> <maxsql> <maxpop> <maxlst> <maxsub> <bwlimit> <hasshell[y]/[n]> <owner> <plan> <maxpark> <maxaddon> <featurelist> <contactemail> <use_registered_nameservers> <language>

yes | /scripts/createacct keralainindia.asia kerala india

Monday, April 1, 2013

Error github: github.com [0: 207.97.227.239]: errno = Connection timed out fatal: unable to connect a socket (Connection timed out)

Error github: github.com [0: 207.97.227.239]: errno = Connection timed out fatal: unable to connect a socket (Connection timed out)

 

git clone -b 6.1.1 git://github.com/wgm/cerb6.git
And got this result:
Cloning into 'cerb6'...
fatal: unable to connect to github.com:
github.com[0: 207.97.227.239]: errno=Connection timed out

 

This error just happens because you have blocked port 9418 on the proxy just enable it and runs smoothly gitbub

 

installing git for single user

cd ~
wget http://git-core.googlecode.com/files/git-1.7.10.1.tar.gz
tar zxvf git-1.7.10.1.tar.gz
cd git-1.7.10.1
./configure --prefix=/home/$USER
make
make install
echo 'PATH=$PATH:$HOME/bin' >> $HOME/.bashrc
source $HOME/.bashrc

named-checkzone and named-checkconf command syntax

named-checkzone {zonename} {filename}
Where,

  • zonename : The domain name of the zone being checked.

  • filename : The name of the zone file.


How do I check my zone file configuration for errors?


Use named-checkzone to check the zone files as follows:
named-checkzone nixcraft.com /var/named/zone.nixcraft.com
Output:
OK

If you see "OK" as result, the zone file is properly configured and you can restart bind name server.

 

How do I check my bind configuration for errors?


Simply run command as follows:
# named-checkconf /etc/named.conf
You may want to chroot to directory so that include directives in the configuration file are processed as if run by a similarly chrooted named:
# named-checkconf -t /var/named/chroot /etc/named.conf
If there is no output, the configuration is considered correct and you can safely restart or reload bind configuration file. If there is an error it will be displayed on screen:
# named-checkconf /etc/named.conf

Kloxo important file location

 



ROUND CUBE



  • /home/kloxo/httpd/webmail/roundcube/logs/errors


Mail



  • /var/log/kloxo/mailog

  • /var/log/kloxo/courier

  • /tmp/horde.log

  • /var/log/kloxo/smtp.log

  • /usr/local/lxlabs/kloxo/mail_send

  • /var/qmail/control/me

  • /var/qmail/control/rcpthosts

  • /var/qmail/control/defaultdomain

  • /var/qmail/control/defaulthost

  • /var/qmail/control/locals

  • /var/qmail/users/assign


Show the users assigned

FTP



  • /var/log/kloxo/pureftpd.log

  • /var/run/pure-ftpd.pid


SSH



  • /var/log/secure


DNS



  • /usr/local/lxlabs/kloxo/log/dns_log


Database



  • /var/log/mysqld.log

  • /usr/local/lxlabs/kloxo/log/database


SSL



  • /var/log/httpd/ssl_error_log


File System



  • /usr/local/lxlabs/kloxo/log/filesys

  • /usr/local/lxlabs/kloxo/log/nonfilesys

  • /usr/local/lxlabs/kloxo/log/remove_oldfile


Bandwitdh



  • /usr/local/lxlabs/kloxo/log/get_traffic


Cron



  • /usr/local/lxlabs/kloxo/log/cron_error

  • /usr/local/lxlabs/kloxo/log/cron_exec

  • /var/spool/cron/


Store the custom crontab per name user inside

Admin



  • /usr/local/lxlabs/kloxo/log/admin_error

  • /usr/local/lxlabs/kloxo/log/login_success

  • /usr/local/lxlabs/kloxo/log/message

  • /usr/local/lxlabs/kloxo/log/user_cmd

  • /usr/local/lxlabs/kloxo/log/access_log


Log every access

Internal



  • /usr/local/lxlabs/kloxo/log/shell_exec

  • /usr/local/lxlabs/kloxo/log/shell_error

  • /usr/local/lxlabs/kloxo/log/other_cmd

  • /usr/local/lxlabs/kloxo/log/syncserveriherit

  • /usr/local/lxlabs/kloxo/log/ajax

  • /usr/local/lxlabs/kloxo/log/error


General error log


  • /usr/local/lxlabs/kloxo/log/update

  • /usr/local/lxlabs/kloxo/log/watchdog

  • /usr/local/lxlabs/kloxo/log/security

  • /usr/local/lxlabs/kloxo/log/run_stats

  • /usr/local/lxlabs/kloxo/log/redirect_error


PHP



  • /usr/local/lxlabs/ext/php/error.log

  • /usr/local/lxlabs/kloxo/httpdocs/.php.err


Lighttpd



  • /home/kloxo/httpd/lighttpd/error.log

  • /home/kloxo/httpd/lighttpd/ligh.log

  • /usr/local/lxlabs/kloxo/log/lighttpd_error.log


Apache



  • /var/log/httpd/error_log


Others



  • /var/log/messages


exiqgrep in detail

Exim includes a utility that is quite nice for grepping through the queue, called exiqgrep. Learn it. Know it. Live it. If you’re not using this, and if you’re not familiar with the various flags it uses, you’re probably doing things the hard way, like piping `exim -bp` into awk, grep, cut, or `wc -l`. Don’t make life harder than it already is.

First, various flags that control what messages are matched. These can be combined to come up with a very particular search.

Use -f to search the queue for messages from a specific sender:
root@localhost# exiqgrep -f [luser]@domain

Use -r to search the queue for messages for a specific recipient/domain:
root@localhost# exiqgrep -r [luser]@domain

Use -o to print messages older than the specified number of seconds. For example, messages older than 1 day:
root@localhost# exiqgrep -o 86400 [...]

Use -y to print messages that are younger than the specified number of seconds. For example, messages less than an hour old:
root@localhost# exiqgrep -y 3600 [...]

Use -s to match the size of a message with a regex. For example, 700-799 bytes:
root@localhost# exiqgrep -s '^7..$' [...]

Use -z to match only frozen messages, or -x to match only unfrozen messages.

There are also a few flags that control the display of the output.

Use -i to print just the message-id as a result of one of the above two searches:
root@localhost# exiqgrep -i [ -r | -f ] ...

Use -c to print a count of messages matching one of the above searches:
root@localhost# exiqgrep -c ...

Print just the message-id of the entire queue:
root@localhost# exiqgrep -i

MANAGING THE QUEUE


The main exim binary (/usr/sbin/exim) is used with various flags to make things happen to messages in the queue. Most of these require one or more message-IDs to be specified in the command line, which is where `exiqgrep -i` as described above really comes in handy.

Start a queue run:
root@localhost# exim -q -v

Start a queue run for just local deliveries:
root@localhost# exim -ql -v

Remove a message from the queue:
root@localhost# exim -Mrm <message-id> [ <message-id> ... ]

Freeze a message:
root@localhost# exim -Mf <message-id> [ <message-id> ... ]

Thaw a message:
root@localhost# exim -Mt <message-id> [ <message-id> ... ]

Deliver a message, whether it’s frozen or not, whether the retry time has been reached or not:
root@localhost# exim -M <message-id> [ <message-id> ... ]

Deliver a message, but only if the retry time has been reached:
root@localhost# exim -Mc <message-id> [ <message-id> ... ]

Force a message to fail and bounce as “cancelled by administrator”:
root@localhost# exim -Mg <message-id> [ <message-id> ... ]

Remove all frozen messages:
root@localhost# exiqgrep -z -i | xargs exim -Mrm

Remove all messages older than five days (86400 * 5 = 432000 seconds):
root@localhost# exiqgrep -o 432000 -i | xargs exim -Mrm

Freeze all queued mail from a given sender:
root@localhost# exiqgrep -i -f luser@example.tld | xargs exim -Mf

View a message’s headers:
root@localhost# exim -Mvh <message-id>

View a message’s body:
root@localhost# exim -Mvb <message-id>

View a message’s logs:
root@localhost# exim -Mvl <message-id>

Add a recipient to a message:
root@localhost# exim -Mar <message-id> <address> [ <address> ... ]

Edit the sender of a message:
root@localhost# exim -Mes <message-id> <address>