|
2009.11.20
 07:22:52
|
|||
|
There are no translations available. I ran into a troublesome error the other day that I thought was worthwhile writing about. When updating an ESX vmware server with YUM (package manager), I encountered a transaction failure message. The message indicates that there was a conflict in the order of the updates. In this case a subversion package that is 64bit is conflicting with a similar 32bit package:
Transaction Check Error: The solution is straightforward. Install a yum plugin that allows the prioritization of which repositories are checked for updates and updated first. In this particular case, I only modified the main base repo. The new lines that were added assign each repo a priority from 1 to 99:
vi /etc/yum.repos.d/CentOS-Base.repo [base]
name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=1 #released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=1 #packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons #baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=2 #additional packages that may be useful [extras] name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=2 #additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus #baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=2 #contrib - packages by Centos Users [contrib] name=CentOS-$releasever - Contrib mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib #baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=2 [dag] name=Dag RPM Repository for Red Hat Enterprise Linux baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag gpgcheck=1 enabled=1 #gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 gpgkey=http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt priority=2 Next, install yum priorities yum install yum-priorities
And finally run yum update again. This time there were no transaction failures!
|
|||
|
2009.09.22
00:24:26
|
|||
|
There are no translations available. For security reasons it is good practice to assign the ESX (vSphere) servers a private IP instead of a public IP. The private IP increases the security of the server since it is not accessible directly over the Internet. However, the ESX server on a private address (IP) cannot sync with the public time server. The same applies to the virtual center (vCenter) if it is also assigned a private IP (and no public IP). It is important to the proper functioning of the ESX servers and vCenter for their timeclocks to be in sync, but using a private address precludes utilizing a publicly available NTP server. The solution to this problem is to use an NTP server that has both a private and public IP. The private IP of the NTP server must be on the same subnet as the ESX or vCenter server for this to work. Once you have an NTP server that is dual homed, then the next task is to update the vCenter server and the ESX servers. The following assumes that the NTP server is on private IP 192.168.0.9. In order to update the ESX servers, you can update them directly via the console or you can use Virtual Center (vCenter), by simply clicking on "Configuration >> Time Configuration >> Properties":
Now click on the "Options" button and then select NTP Settings. There you will be able to add the NTP server's IP address. You should also remove any other NTP servers that you don't need such as 127.127.0.0.1.
Make sure the "NTP Client Enabled" checkbox is selected because otherwise, the firewall port 123 will remain closed and NTP will fail. To see the failure condition more clearly, I logged onto one of the ESX servers to see the error message produced when attempting to start up the NTP daemon: ntpd restart Shutting down ntpd: [FAILED]
In order to update vCenter so that it too is reliant on an NTP server on a private IP, you'll need to use regedit (registry editor). There are many other documents on the Internet that talk about how to do this, so I will recap here: For more details google "NTP server registry update" or view this article: http://www.windowsnetworking.com/articles_tutorials/Configuring-Windows-Time-Service.html Change this registry entry to "NTP": HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type Change this registry to "5": HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags Change this registry to the IP of the NTP server (i.e., 192.168.0.9) HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer Finally, restart the network time services:
Give it a few minutes and the clock will then show the synchronization with the NTP server on the private IP:
Now the servers are more secure on a private IP address AND they are in sync by using a dual-homed NTP server.
|
|||
|
2009.04.17
00:18:46
|
|||
|
There are no translations available.
Virtualization has solved an array of IT problems for companies around the globe, and it promises to expand its reach in the future to cover an even wider range of scenarios. However, virtualization isn't a silver bullet that can solve all of IT's woes -- nor is it suited for all companies. There are circumstances when ESX virtualization may not be ideal for you.
ESX Virtual Hosting is Not Ideal if:
By considering each of these scenarios, hopefully you can start to see if virtualization is right for you, and what steps you might need to take before virtualizing your servers.
|
|||