Adding New HDD to Linux Machine

#fdisk -l

After enter this command we will view as:
------------
fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 1305 10377990 8e Linux LVM

Disk /dev/sdb: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdb doesn't contain a valid partition table
------------
Now we need to add available disk using:

# fdisk /dev/sdb

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 1044.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1044, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1044, default 1044):
Using default value 1044

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
------------
Now we need to format the disk to make available:

# mke2fs -j /dev/sdb1
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1048576 inodes, 2096474 blocks
104823 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648
64 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
#
------------

Now we can mount the same in available directory:

mount /dev/sdb1 /temp

VNC alias in MAC OS X Server

alias vncrestart='/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console'

How to Change Files owner and Group in Linux

chown -R username:groupname Directory

Configure a system to automount a Samba share with /etc/fstab

We can use the mount command to mount a remote windows partition or a windows share under Linux.

/etc/fstab file contains static information about the filesystems. The file fstab contains descriptive information about the various file systems. fstab is only read by programs, and not written; it is the duty of the system administrator to properly create and maintain this file.

To mount a Samba share to be mounted when a Linux system comes up after reboot edit the /etc/fstab file and put entry as follows for your Windows/Samba share:
//ntserver/share /mnt/samba smbfs username=username,password=password 0 0

For example, if you want to mount a share called //ntserver/docs then you need to write following entry in /etc/fstab file://ntserver/docs /mnt/samba smbfs username=docsadm,password=D1Y4x9sw 0 0Where,

• //ntserver/docs: Windows 2003/NT/Samba share name
• /mnt/samba: Local mount point (you may need to create this directory first)
• smbfs: File system type (samba file system)
• username=docsadm,password=D1Y4x9sw: Share username and password

Open file /etc/fstab using vi text editor:# vi /etc/fstabAppend line //ntserver/docs /mnt/samba smbfs username=docsadm,password=D1Y4x9sw 0 0, at the end your file should read as follows:

proc /proc proc defaults 0 0
/dev/hdb1 / ext3 defaults,errors=remount-ro 0 1
/dev/hdb2 none swap sw 0 0
/dev/hdc /media/cdrom0 iso9660 ro,user,noauto 0 0
//ntserver/docs /mnt/samba smbfs username=docsadm,password=D1Y4x9sw 0 0

Replace sharename, username and password with your actual parameters.

Procedure to mount remote windows partition (NAS share)

1) Make sure you have following information:

==> Windows username and password to access share name

==> Sharename (such as //server/share) or IP address

==> root level access on Linux

2) Login to Linux as a root user (or use su command)

3) Create the required mount point:

# mkdir -p /mnt/ntserver

4) Use the mount command as follows:

# mount -t cifs //ntserver/download -o username=vivek,password=myPassword /mnt/ntserver

Use following command if you are using Old version such as RHEL <=4 or Debian <= 3:

# mount -t smbfs -o username=vivek,password=D1W4x9sw //ntserver/download /mnt/ntserver

5) Access Windows 2003/2000/NT share using cd and ls command:

# cd /mnt/ntserver; ls -l

Where,

• -t smbfs : File system type to be mount (outdated, use cifs)
• -t cifs : File system type to be mount
• -o : are options passed to mount command, in this example I had passed two options. First argument is password (vivek) and second argument is password to connect remote windows box
• //ntserver/download : Windows 2000/NT share name
• /mnt/ntserver Linux mount point (to access share after mounting)

Quickly - How to determine the ESX host version?

The easiest way how to find out the ESX host version, is to log in to the service console and use the esxupdate command. The major version can be found in the file /etc/vmware-release. For example, it may contain:

VMware ESX Server 3

So, the major version is 3.x. To determine minor version is a little complicated. Run this command from service console:

esxupdate query

And try to identify patches with the following prefixes from the end of command output (the last one is the right one):

1. ESX - the minor version should be 0, so we have version 3.0.x
2. ESX350 - the minor version is 5, the version is 3.5.0
3. 3.5.0 - initial instalation of version 3.5.0
   

The corresponding lines may look like these:

3.5.0-64607    16:25:29 05/27/08 ESX 3.0.x to 3.5.0-64607 upgrade
3.5.0-64607    10:42:31 08/06/08 Full bundle of ESX 3.5.0-64607

It remains to identify the update level. Use the same command as above and check the full patch name now:

1. ESX350-Update01 - we have 3.5.0 Update 1
2. ESX350-Update02 - we have 3.5.0 Update 2

The corresponding lines are:

ESX350-Update01    16:59:56 05/27/08 ESX Server 3.5.0 Update 1
ESX350-Update02    10:42:38 08/06/08 ESX Server 3.5.0 Update 2
-------------------------------------------------------------------------------------

Another quick way to get the version of ESX, would be to run a:

# vmware -v
VMware ESX Server 3.0.1 build-32039

MYSQL Database Restoration in Linux

Please run below command that from where you want to take database to restore:

/usr/bin/mysqldump --user=proftpd --password=proftpd --opt --skip-lock-tables --single-transaction --default-character-set=binary --databases mds > MDS_Dump.sql

Note:- If we know the root password of the mysql, then use that credentials, after that zip MDS_DUMP.sql file and tranfer it into destination server.

To restore Please use below script:-
---------------------------
#!/bin/bash
#
# Script for restoring Database database.
# Modified by Sravan Kumar E
#

echo "Restoration staDatabaseed at: `date`" >> /tmp/restore.log
FILENAME=`date +%d-%b-%Y`
if [ -f /tmp/Database_Dump_?????????${FILENAME}.sql.gz ]
then
gunzip -d /tmp/Database_Dump_?????????${FILENAME}.sql.gz
mysqladmin --user=root --password=******** -f drop Database3 >> /tmp/restore.log 2>>/tmp/restore.log
RESTORE_FILE=`echo /tmp/Database_Dump_?????????${FILENAME}.sql`
echo "ImpoDatabaseing the data from ${RESTORE_FILE}" >> /tmp/restore.log
mysql --user=root --password=c1b8rn8t < ${RESTORE_FILE} gzip /tmp/Database_Dump_?????????${FILENAME}.sql rm -f /tmp/Database_Dump_?????????${FILENAME}.sql echo "Restoration completed at: `date`" >> /tmp/restore.log

else
echo "Restore Failed because of non availability of proper file" >> /tmp/restore.log
fi
-----------------------------

ESX Upgrade Process:

• Back Up ESX Host Configuration
• Post upgrades Considerations for Hosts:
• Clean up ESX Boot loader Menu after Upgrade:
• Restore ESX Host Configuration
• Upgrading Virtual Machines:
• Downtime for Upgrading Virtual Machines
• Perform an Interactive Upgrade of VMware Tools on a Microsoft Windows Guest
  
  

Back Up ESX Host Configuration:-

Before we upgrade an ESX host, back up the local VMFS file system. This ensures that you will not lose data during the upgrade.

Procedure:

1. Back up the files in the /etc/passwd, /etc/groups, /etc/shadow, and /etc/gshadow directories. The /etc/shadow and /etc/gshadow files might not be present on all installations.

2. Back up any custom scripts.

3. Back up your .vmx files.

4. Back up local images, such as templates, exported virtual machines, and .ISO files.

Post upgrades Considerations for Hosts:

A host upgrade is not entirely complete until after you have ensured that the host management, configuration, and licensing is in place.

After upgrade an ESX/ESXi host, consider the following:

View the upgrade logs.

For ESXi, you can use the vSphere Client to export the log files.

For a successful ESX upgrade, we will find upgrade log files at these locations on the host:

• /esx3-installation/esx4-upgrade/
• /var/log/vmware/

For an unsuccessful ESX upgrade, we will find upgrade log files at these locations on the host:

• /esx4-upgrade/
• /var/log/vmware/

Clean Up the ESX Boot loader Menu After Upgrade:

After determine that the ESX 4.0 upgrade is stable, we can remove the ESX 3.x boot option from the ESX 4.0 boot loader menu to disable the ability to roll back to ESX 3.x.

After upgrade a host from ESX 3.x to ESX 4.0, the ESX boot loader boots into ESX 4.0 by default, but retains the option to boot into ESX 3.x. The ESX 3.x boot option is useful if the ESX 4.0 upgrade does not work as expected in your environment. However, after you confirm that the upgrade is stable, you might want to disable the ability to roll back to ESX 3.x.

This procedure is applicable only if we left the default rollback option enabled when we performed the upgrade. If we deselected the rollback option, this procedure is not applicable. Only a system administrator can perform this optional procedure.

Prerequisites

Before executing this script, make sure that we have copied all required data from the legacy ESX mount points under /esx3-installation.

Procedure

1 In the ESX 4.0 service console, run the cleanup-esx3 command with the optional -f (force) flag.

If we omit -f flag, the software prompts us to confirm to disable the ability to roll back to the ESX 3.x.

2 (Optional) Reboot the host.

While the server is powering on, observe that the boot loader menu does not include an option for ESX 3.x.

The host looks the same as a clean installation of ESX 4.0. The cleanup-esx3 script removes the following files and references from the ESX 4.0 host:

1. ESX 3.x references in the /etc/fstab directory
2. ESX 3.x boot files in the /boot directory
3. The rollback-to-esx3 script in the /usr/sbin/ directory

Restore the ESX Host Configuration:

If we backed up our ESX service console and VMFS files, we can restore our original ESX host configuration.

Procedure

1 Reinstall the original version of ESX on the host. See the Installation Guide.

2 Restore the backed-up service console and local VMFS files.

See http://www.vmware.com/resources/techresources/610

Upgrading Virtual Machines:

The first step in upgrading virtual machines is to upgrade VMware Tools. If the virtual machines do not have VMware Tools installed, you can use the VMware Tools upgrade procedure to install VMware Tools. After you install or upgrade VMware Tools, upgrade the virtual machine hardware.

VMware offers the following tools for upgrading virtual machines:

vSphere Client Requires you to perform the virtual machine upgrade one step at a time.

Downtime for Upgrading Virtual Machines:

When we upgrade virtual machines, the required downtime varies depending on the guest operating system.

The following procedures are involved in upgrading virtual machines:

• Upgrade VMware Tools
• Upgrade virtual hardware

During VMware Tools upgrade, the virtual machine remains powered on for Microsoft Windows Operating systems, you must reboot the guest operating system at the end of the VMware Tools upgrade.

For Linux, Netware, and Solaris guest operating systems, no reboot is required at the end of the VMware Tools upgrade.

When we upgrade VMware Tools, expect downtime as follows:

• No downtime is required for vCenter Server.
• No downtime is required for ESX/ESXi hosts.
• You must reboot the virtual machine at the end of the upgrade procedure, or later, to make the upgrade.

Upgrade Effectiveness:-

On Windows guest operating systems, you must reboot the virtual machine a total of three times when

you upgrade VMware Tools and the virtual hardware:

1. Power on the virtual machine.
2. Upgrade VMware Tools.
3. Reboot the virtual machine at the end of the VMware Tools upgrade.
4. Power off the virtual machine.
5. Upgrade the virtual Hardware.
6. Power on the virtual machine.
7. The Windows operating system detects new devices and prompts you to reboot the virtual machine.
8. Reboot the virtual machine to make the devices work properly.
9. During the virtual hardware upgrade, the virtual machine must be shut down for all guest operating systems.

Perform an Interactive Upgrade of VMware Tools on a Microsoft Windows Guest:-

Upgrade VMware Tools to the latest version to enhance the performance of the virtual machine's guest operating system and improve virtual machine management.

Prerequisites

• Back up your virtual machines to prevent data loss. See Basic System Administration.
• A supported guest operating system must be installed on the virtual machine.
• You must have an ESX/ESXi license or be using evaluation mode to power on the virtual machine.

Procedure:-

1) From the vSphere Client, right-click the virtual machine, select Power, and select Power On.

2) Select the virtual machine and click the Summary tab.

The VMware Tools label indicates whether VMware Tools is installed and current, installed and not

Current, or not installed.

3) Click the Console tab to make sure that the guest operating system starts successfully and log in if

necessary.

4) Right-click the virtual machine, select Guest, and select Install/Upgrade VMware Tools.

5) Select Interactive Tools Upgrade and click OK.

The upgrade process starts by mounting the VMware Tools bundle on the guest operating system.

6) If the Microsoft Windows New Hardware wizard appears in the virtual machine console, complete the

wizard and accept the defaults.

• Upgrading virtual hardware and installing or upgrading VMware Tools includes enhancements to the virtual network adapter. A Microsoft Windows guest operating system might interpret these changes as indicating a different network adapter in the virtual machine and start the New Hardware wizard accordingly.

7) In the virtual machine console, do one of the following:

• If autorun is enabled, click OK to confirm that you want to install VMware Tools and start the InstallShield wizard.
• If autorun is not enabled, manually start the VMware Tools installer, by clicking Start > Run and entering D:\setup.exe, where D: is your first virtual CD-ROM drive.

8) Follow the onscreen instructions.

9) Reboot to make the changes take effect.

The VMware Tools label on the Summary tab changes to OK.

What to do next

(Recommended) Upgrade the virtual machine hardware to version 7.