Archive for May, 2010

Redhat – Changing Timezone

Posted: May 31, 2010 in Redhat

How do I change my system timezone from the command line without using redhat-config-date?

In order to change the timezone of your system you will need to access the file /etc/sysconfig/clock directly:


#ZONE="America/New_York"
ZONE="GMT"
UTC=false
ARC=false

Note: If your system’s BIOS has UTC set to true, then set UTC to true. If it has it set to false, set it to false. UTC in the configuration file must always reflect your BIOS settings.

In order to get the particular zone you wish to use you must associate ZONE with a file located in /usr/share/zoneinfo. It is wise to note the directory structure because if you need to set the timezone to that of Shanghai which is located in the Asia directory you will then have to set your ZONE variable to the following :

ZONE="Asia/Shanghai"

Or perhaps you need to set the timezone to that of East Brazil :

ZONE="Brazil/East"

Finally save the file /etc/sysconfig/clock and on next reboot the system will be set to the defined timezone.

For the time on the machine to reflect the change timezone we need to link the zoneinfo file to /etc/localtime. This can be done as follows :

If you are setting your timezone to “Brazil/East” link the following file to /etc/localtime :

# ln -sf /usr/share/zoneinfo/Brazil/East /etc/localtime

Now by typing the date command to display the time you should see if reflect the newly linked timezone :

# date
Thu Sep 30 10:06:23 BRT 2004


The majority of all the networking configuration you will need to perform on VMware ESX boils down to just a couple commands:

* esxcfg-vswitch: You will use this command to manipulate virtual switches (vSwitches) and port groups.
* esxcfg-nics: You will use this command to view (and potentially manipulate) the physical network interface cards (NICs) in the VMware ESX host.

Configuring VMware ESX networking boils down to a couple basic tasks:

1. Creating, configuring, and deleting vSwitches
2. Creating, configuring, and deleting port groups

I’ll start with creating, configuring, and deleting vSwitches.
Creating, Configuring, and Deleting vSwitches

You’ll primarily use the esxcfg-vswitch command for the majority of these tasks. Unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a vSwitch, use this command:

esxcfg-vswitch -a (vSwitch Name)

To link a physical NIC to a vSwitch—which is necessary in order for the vSwitch to pass traffic onto the physical network or to receive traffic from the physical network—use this command:

esxcfg-vswitch -L (Physical NIC) (vSwitch Name)

In the event you don’t have information on the physical NICs, you can use this command to list the physical NICs:

esxcfg-nics -l (lowercase L)

Conversely, if you need to unlink (remove) a physical NIC from a vSwitch, use this command:

esxcfg-vswitch -U (Physical NIC) (vSwitch Name)

To change the Maximum Transmission Unit (MTU) size on a vSwitch, use this command:

esxcfg-vswitch -m (MTU size) (vSwitch Name)

To delete a vSwitch, use this command:

esxcfg-vswitch -d (vSwitch Name)
Creating, Configuring, and Deleting Port Groups

As with virtual switches, the esxcfg-vswitch is the command you will use to work with port groups. Once again, unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a port group, use this command:

esxcfg-vswitch -A (Port Group Name) (vSwitch Name)

To set the VLAN ID for a port group, use this command:

esxcfg-vswitch -v (VLAN ID) -p (Port Group Name) (vSwitch Name)

To delete a port group, use this command:

esxcfg-vswitch -D (Port Group Name) (vSwitch Name)

To view the current list of vSwitches, port groups, and uplinks, use this command:

esxcfg-vswitch -l (lowercase L)

Redhat – SSHD canot start

Posted: May 25, 2010 in VMware

Error :

May 25 22:21:20 aurhel05 sshd[9062]: Server listening on :: port 22.
May 25 22:21:20 aurhel05 sshd[9062]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.

Solution :

Initialy I thouht it isa problem related to sshd conf file . Palying around with it and at the end canot find any solution . Bit Haressment in early Monday Morning 😦

Then got the solution in the following site . It is basically clashing each other with IPV6 AND IPV4.

They say that by disabling IPv6 things get a bit smoother and faster regarding networking. I don’t really know if this is true, but I guess, if you’ve decided to disable this feature, you probably care to do it the Right Way™. As far as I know, trying to disable IPv6 through anaconda during the installation of Fedora or CentOS does not turn off the IPv6 functionality completely, but it just disables it for the configured network interface. This is not actually a problem, but, why should this network layer be enabled system-wide, if you do not use it at all? This small article assists you in disabling IPv6 in the latest Fedora and CentOS releases in an aggressive and unforgiving way.

Check if the module is loaded

IPv6 functionality is being made available to the system by the ipv6 kernel module. To check if this module is currently loaded in your system, issue the following command as root:

lsmod | grep ipv6

If you see ipv6 in its output, then the module is loaded.

Performing this check is absolutely not necessary. It is included in this article for completeness.

Disable IPv6

You can prevent a module from being inserted into the kernel by either blacklisting it or by completely disabling it.

In this case, since you will most probably turn off the IPv6 firewall (ip6tables) as well, it is highly recommended to completely disable the ipv6 module, to avoid any accidental loading of the IPv6 stack without any firewall protection at the same time.

How the module blacklist works

This information about blacklisting a kernel module exists here for educational purposes. It has been mentioned above that for ipv6 it is important to completely disable it.

From the modprobe.conf man page:

Modules can contain their own aliases: usually these are aliases describing the devices they support, such as “pci:123…”. These “internal” aliases can be overridden by normal “alias” keywords, but there are cases where two or more modules both support the same devices, or a module invalidly claims to support a device: the blacklist keyword indicates that all of that particular module’s internal aliases are to be ignored.

So, blacklist indicates that a module’s aliases should be ignored. But, what happens if an application requires to load that specific module or if root uses modprobe to load it on demand? Let’s test it…

To blacklist the module, simply save the following line in a file inside /etc/modprobe.d:

blacklist ipv6

Next, disable any services that use IPv6, eg ip6tables or any IPv6-enabled network interfaces and reboot (mandatory).

After you’ve logged-in again, try, for example, to load the ipv6 module with the modprobe command (as root):

[root@centos]# modprobe -v ipv6
insmod /lib/modules/2.6.18-53.1.14.el5/kernel/net/ipv6/ipv6.ko
[root@centos]# lsmod | grep v6
ipv6 251393 8

The blacklisted module has been loaded. This is what happens if it is needed by a system service, regardless of the fact that it has been blacklisted. In the case of ipv6 this could be a security risk, provided that the ipv6 firewall has been turned off but some network interfaces still use IPv6. So, frankly, it is suggested to read on how to disable the module more aggressively…

Completely disable the ipv6 module

To completely disable IPv6 in your system, all you have to do is save the following line in a file inside /etc/modprobe.d/.

install ipv6 /bin/true

The above line means: whenever the system needs to load the ipv6 kernel module, it is forced to execute the command true instead of actually loading the module. Since /bin/true, does absolutely nothing, the module never gets loaded.

Again, it is required to reboot for the changes to take effect.

It is obvious that this is an aggressive method to disable kernel modules, but it guarantees that the module never gets loaded.

This is the recommended way to disable IPv6.

Other Configuration Tasks

Since the IPv6 functionality has been disabled, you can disable the ip6tables service (IPv6 Firewall). Issue the following command as root:

chkconfig ip6tables off

It is also a good idea, since the ip6tables service has been turned off, to disable any IPv6-related functionality in the network interface configuration. Even if you do not do this, the IPv6 stack will not be initialized because the ipv6 module cannot be loaded. But, generally, you could set the following options to “no” inside your network interface scripts, for example: /etc/sysconfig/network-scripts/ifcfg-eth0

IPV6INIT=no
IPV6_AUTOCONF=no

Finally, In fedora 8 or newer you can safely remove the following option from the /etc/sysconfig/network file, if it exists:

NETWORKING_IPV6=no

Final Thoughts

Using the instructions above, you can completely disable IPv6 in your system. On the other hand, you should understand that IPv6 is not an evil thing… It exists in order to address certain issues. If you ever think about actually trying to configure and use it instead of just disabling it every time you install your Linux operating system, here is a good place to start

Reference :

http://www.g-loaded.eu/2008/05/12/how-to-disable-ipv6-in-fedora-and-centos/

Redhat – Sendmail Open Relay

Posted: May 25, 2010 in Redhat

The access database (normally in /etc/mail/access) allows a mail administrator to administratively allow access to the mail server by individual domains. Each database entry consists of a domain name or network number as the key and an action as the value.

Keys can be a fully or partly qualified host or domain name such as host.subdomain.domain.com, subdomain.domain.com, or domain.com. The last two forms match any host or subdomain under the specified domain. (If FEATURE(relay_hosts_only) is set, only the first form works.) Keys can also be a network address or subnetwork, e.g., 205.199.2.250, 205.199.2, or 205.199. The latter two forms match any host in the indicated subnetwork. Lastly, keys can be user@host.domain to reject mail from a specific user.

Values can be REJECT to refuse connections from this host, DISCARD to accept the message but silently discard it (the sender will think it has been accepted), OK to allow access (overriding other built-in checks), RELAY to allow access including relaying SMTP through your machine, or an arbitrary message to reject the mail with the customized message.

For example, a database might contain:

cyberpromo.com REJECT sendmail.org RELAY spam@buyme.com 550 Spammers shan't see sunlight here

to reject all mail from any host in the cyberpromo.com domain, allow any relaying to or from any host in the sendmail.org domain, and reject mail from spam@buyme.com with a specific message.

Note that the access database is a map and just as with all maps, the database must be generated using makemap. For example:

makemap hash /etc/mail/access < /etc/mail/access

Manually Check for Open-Relay :

telnet 1.1.1.1 25

Server responds with: 220 mx.mydom.com SMTP
HELO

Server responds with: 250 OK
MAIL FROM:user@mydom.com

Server responds with: 250 Address Ok.
RCPT TO:user@otherdom.com

Server responds with: 250 user@otherdom.com OK
DATA

Server Responds (or may not): 354 Enter Mail
Enter message, then on a new line,
.

exit

The message should now be sent. By modifying the MAIL FROM and RCPT TO lines, you can test for open relay.

Open Relay Test from Web Site :

http://spamlinks.net/prevent-secure-relay-test.htm


1) Backup image to TFTP server
Router>enable
Router#copy flash:{your IOS image filename} tftp://{TFTP server IP address}

2) Download image from TFTP server
Router>enable
Router#copy tftp://{TFTP server IP address} flash:

Example :

SW-AU-G3#cop flash: tftp
Source filename []? flash:c3560-ipbase-mz.122-25.SEE3/c3560-ipbase-mz.122-25.SEE3.bin
Address or name of remote host []? 10.80.0.102
Destination filename [c3560-ipbase-mz.122-25.SEE3.bin]?
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!…!!!!!
6427865 bytes copied in 56.624 secs (113518 bytes/sec)


Great news for all you VMware architects and administrators out there! VMware have just made available the final release of the VMware vSphere hardening guide for download. This is a must read in my opinion as it provides some excellent tips and best practices that can easily be applied to your vSphere environment.

The guide is split into the following logical topic areas; Virtual Machine, ESX/ESXi Host, vNetwork, vCenter and Console Operating System (COS). As mentioned on the hardening guide’s announcement page here, this vSphere version of the guide has the following “highlights”:

Structure: this version uses a standardized format, with formally defined sections, templates, and reference codes. The goal is to increase clarity and reduce ambiguity, make it easier to reference individual guidelines, and most of all, enhance the ability to automate guideline enforcement.

Recommendation levels: in following with the formats used by NIST, CIS, and others, this guide categorizes all guidelines into three security levels. Instead of recommending a single set of guidelines for all environments, this guide encourages more of a risk-based approach, so that individual administrators can decide which guidelines apply to their environment.

The vSphere hardening guide can be download from the VMware Security Team’s blog here.


Until recently I had been running my ESX VM’s on local disk. This is mostly due to not having enough time to get some shared storage up and running.

I however was determined to get something up and running for my ESX lab so that I can play around with some of ESX’s more powerful, and interesting, features such as DRS, HA and VMotion.

As with most of you money is a serious consideration so as I am not in a position to implement a fibre attached SAN solution – though this would be nice. The next best option is iSCSI. I am running both VMware ESX 3.5 and ESXi 3.5 in my lab and both provide iSCSI functionality by default to connect through to an iSCSI target.

There are a handful of good free (free is always good :) ) iSCSI software that can be downloaded. Some are standalone installs, others come in the form of virtual appliances and some both.

Here is a list of those that I know of (there will no doubt be many more):

I decided to give OpenFiler a go – as I’d heard good things about the latest release, v2.3. Here’s a link to a really good document on the OpenFiler site that details the underlying architecture.How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

The download link to OpenFiler can be found here.

As you can see there are many different downloads available. I decided to install it on old Shuttle XPC PC I had lying about. This server has 1GB of memory, Single AMD64 2GHz CPU and a single Gigabit NIC all of which are more than adequate for running OpenFiler. I downloaded and installed the x86_64 version.

How to configure OpenFiler v2.3  iSCSI Storage for use with VMware ESX

I then burnt the ISO to CD and installed OpenFiler using the great graphical step by step installation guide provided on their web site.

For this lab install I have used the following network configuration.

Shuttle  XPCOpenFiler (Shuttle PC)
NIC: Single port 1Gb
IP: 10.0.0.1/24

ML110 G5 ESX Server (ML110 G5)
ESXi 3.5.0 U3
NIC: Dual port NIC
IP#1 (iSCSI): 10.0.0.10/24
IP#2 (General Traffic): 192.168.1.11/24

ML115 G5 Management Server (Home Brew PC)
OS: Windows 7
NIC: Dual port NIC
IP#1 (iSCSI network – for management of OpenFiler): 10.0.0.2/24, IP#2 (General Traffic): 192.168.1.1/24

Once you have OpenFiler installed you can then access a web based management console which allows you to configure your new OpenFiler installation.

Opening a web browser and pointing it to the IP address (ie: https://:446&gt; of the OpenFiler server you should be presented with a logon screen like that below (love the fat Linux penguin).

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

At the prompt enter ‘openfiler’ for the ‘Username’ and ‘password’ for the password. These details can be changed once you’ve successfully logged onto the management portal along with the ability to create additional accounts and groups.

Step 1 – Network Access Configuration:

The first thing to do is set up the ‘Network Access Configuration’. This is the host or subnet (depending on how granular you want the access to be) you wish to provide access from. Select the ‘System’ tab and from the ‘Network Access Configuration’ section at the bottom of the page enter in either the IP from which you wish to access the OpenFiler from or enter in a whole subnet from which the Open filer will accept traffic from.

As I am running a secure lab environment I am just going to enter in the whole subnet for ease. You may want to be a little more granular if using this in a production or non-secure environment.

Make sure that the ‘Type’ is set to ‘Share’.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Volumes – Important Information (for the clarity of mind).

Before we go any further I just want to point out some potential confusion that can arise when creating, assigning and configuring the various ‘Volume’ parameters within OpenFiler. There are 3 volume items we’ll be dealing with in the next few steps. I personally found this a little confusing at first so thought I’d try and throw down some clarification around this area:

1. Physical Volume – Assigning space on a physical disk for use in a Volume Group.

2. Volume Group – Contains Physical Volumes from which a Logical Volume will be created.

3. Logical Volume (LUN) – This is what is presented through to a server (eg: ESX).

Now with that out of the way.. on with the show!

Follow these steps in order to configure your OpenFiler SAN and present it through to VMware ESX/ESXi.

Step 2 – Create a New Physical Volume:

We need to create a physical volume which we will then present through to a Volume Group. To do this select ‘Block Devices’ from the ‘Volumes section’ menu.How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Select ‘Edit Disk’ on the hard disk you want to create this new physical volume.

Scroll to the bottom of the screen and you will see the available spare space on this disk along with some other parameters. If you are not intending to create a RAID set for your physical volume then select ‘Physical volume’ as your partition type and select the ‘Mode’ as ‘Primary’.

Adjust the start and end cylinders to determine the size of physical volume and when satisfied press the ‘Create’ button.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

You will then be shown a summary of the partitions on this disk. Notice that the ‘Physical Volume’ I just created appears on the list (bottom).How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Step 3 – Create a New Volume Group:

Next we want to create a new ‘Volume Group’ for the ‘Physical Volume’ we created to reside in. Click on the ‘Volumes’ tab and then select ‘Volume Groups’ from the ‘Volume section’ menu on the right hand side menu.

Enter in a ‘Volume group name’ and select (check box) the physical volume to which you wish to associate the Volume Group. Then press ‘Add Volume group’How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

You should now be presented with a new Volume Group that looks like this:

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Step 4 – Create a Volume:

We now want to create a ‘Volume’. Click on ‘Add volume’ from the right hand ‘Volumes section’ menu.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Now select the ‘Volume Group’ you just created and press the ‘Change’ button. You will now be presented with the following screen where you determine the size of the ‘Volume’ your going to create within your ‘Volume Group’.

For this example I’m going to create a ‘Volume’ that occupies the entire space of the ‘Volume Group’. Enter in the ‘Volume Name’ and determine the size by either keying in the required space or using the slider bar. Then for the ‘Filesystem/Volume type’ select ‘iSCSI’. This lasts part is important to all of this working so make sure it is set correctly (ie: iSCSI)!

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

When your happy with your settings press the ‘Create’ button.

Once the ‘Volume’ is created you will be greeted with a screen with a nice big green coloured pie chart in it which is indicating the amount of the ‘Volume Group’ that the volume has consumed. Which in this example is all of it.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

This is now everything to do with creating a volume completed. We now want to enable the connectivity side of things (ie: allowing other PCs/Servers to connect to the OpenFiler SAN).

Step 5 – Enable the iSCSI Target Service:

Click on the ‘Services’ tab of the main window.

Next click on the ‘Services’ tab and enable the ‘iSCSI target server’ (see below). By default it is set to ‘Disabled’. For connecting the OpenFiler SAN through to an VMware ESX/ESXi host we don’t need any of the other services enabling.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Step 6 – Add an iSCSI Target:

Returning to the ‘Volumes’ section of the OpenFiler web interface select ‘iSCSI Targets’ from the ‘Volumes section’ menu on the right hand side of the screen.

We first want to create a new iSCSI target and do by select the first sub-tab called ‘Target Configuration’ in the ‘iSCSI Targets’ section. I personally keep the default ‘Target IQN’ generated by OpenFiler though you can alter it at this stage if your want. Now press the ‘Add’ button.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

You will now be given a screen with a summary of the settings for the new iSCSI Target.

Step 7 – Map the LUN:

Now select the ‘LUN Mapping’ tab and click on the ‘Map’ button. There are no other settings that need changing.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

Step 8 – Allow access to the iSCSI Target:

Select the ‘Network ACL’ tab and from the ‘Access’ drop down list box select ‘Allow’ (Note: it is set to ‘Deny’ by default) and then press the ‘Update’ button. This allows the IP range we defined in step 1 access to the iSCSI Target we just created.

How to  configure OpenFiler v2.3 iSCSI Storage for use with VMware ESX

You may have noticed the next menu tab which is called ‘CHAP Authentication’. In this section you would specify a logon name and password with incoming access to this iSCSI target. I am not worrying about configuring this as it is just a temporary set up for my test lab. Though if you are think about setting something up which will be a little more permanent then I’d definitely recommend enabling CHAP authentication. This’ll need enabling and these credentials specifying on the ESX side of things – but is very easy to do.

Open Filer Configuration Stage Finished!

This is now a basic OpenFiler configuration up and running with a LUN ready to be added to ESX.

IMPORTANT NOTE: If you are ever thinking of implementing OpenFiler for use with ESX in a production environment then it is highly recommended to keep the iSCSI network separate (for security and performance) from all other general type traffic and to apply CHAP’s encryption. In my lab I have created two VLAN’s on my Linksys SLM2008. One for general network traffic and the other for the iSCSI traffic.

Step 9 – VMware ESX iSCSI Configuration:

Open up the VMware Virtual Infrastructure Client (VIC) and select the ESX server that you want to add the iSCSI storage to. From the ‘Configurations’ tab in the right pane select ‘Networking’. You will now be presented with the networking configuration for that ESX server.

ESX  iSCSI Configuration

As you can see my particular install of ESX is using ESXi.

I have created a second Virtual Switch and have allocated a VMKernel port on the second NIC port (which is patched into the 10.0.0.0/24 VLAN) which I have given a 10.0.0.11/24 IP address. The is the port that the iSCSI traffic will use.

If you are configuring this using ESX 3.5 then you will also have to add a ‘Service Console’ port to this newly created Virtual Switch. If you don’t do this you’ll get this friendly reminder:

ESX  iSCSI Configuration

We now want to look at the ‘Storage Adapters’. Click on this option in the ‘Hardware’ menu.ESX  iSCSI Configuration

You will see that there is an iSCSI Software Adapter already in place – though currently not enabled. All that needs doing is to configure and point it to the OpenFiler LUN(s). Notice how all the iSCSI related details are currently blank.

Click on the ‘iSCSI Software Adapter’ and select ‘Properties’.

ESX  iSCSI Configuration

The status of the iSCSI Software Adapter is initially set to ‘Disabled’. We want to enable it and assign the relevant details. Click on ‘Configure’. Check the ‘Enable’ status box and click ‘Ok’

ESX  iSCSI Configuration

The iSCSI properties will now be populated (see below). I won’t go into the format of the iSCSI name and alias though the VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide has a good section on iSCSI and explains these details.

ESX  iSCSI Configuration

Clicking on the ‘Dynamic Discovery’ tab and selecting ‘Add’ we are presented with an ‘Add Send Targets Server’ dialogue box. This is where we’ll enter the IP address of our OpenFiler server/SAN. (Note: the ‘Static Discovery’ tab is only used when using a hardware iSCSI initiator)

ESX  iSCSI Configuration

After entering in this IP information and pressing ‘Ok’ it can take a little while before iSCSI server is detected.

ESX  iSCSI Configuration

With these new iSCSI setting we are prompted to re-scan the host. Select ‘Yes’

ESX  iSCSI Configuration

After ESX has finished its re-scan you should now see the LUN(s) appear that you created in OpenFiler.

ESX  iSCSI Configuration

With this shared storage and a couple of ESX servers you can now start using some of the more interesting and powerful features of VMware ESX such as VMotion and HA (assuming you have the appropriate license :) ).

As mentioned this is purely intended as a rough guide to getting OpenFiler up and running with VMware ESX. OpenFiler has plenty of other great features and is worth investing some time into.

Hope this guide helps. Good Luck!