Install VMware vSphere Client on Domain Controller Machine

As VMware admin’s ,we are so much used to work with vSphere windows client against vSphere web Client. Have you tried to installing vSphere client on Domian controller machine. By default, that is not possible. When we try to install vSphere windows client on Domain Controller, We may end up with the error message” vSphere Client fails with a message saying the as a requirements the management station has to be running XP SP2 and not a domain controller”. For people running Lab environment, Will not prefer to install another windows VM just to install vSphere client. In that situation, You can make use of this OS SKIP command to install the vSphere client on Windows Domain controller as a workaround.
Below is the error message you will receive, when you try to install vSphere client on Windows Domain Controller machine.
 You can use an advanced switch when installing VI client on Domain Controller . You can launch the installer from a command line and in this case there is a switch to use which skips the OS check. Here is the command to use:
VMware-viclient.exe /VSKIP_OS_CHECKS=”1″

RHEL 7 : systemd

As the Systemd now replaces SysVinit, it is time to get familiar with it and learn new commands.
Systemd is quicker because it uses fewer scripts and tries to run more tasks in parallel (Systemd calls them units).
The Systemd configuration is stored in the /etc/systemd directory.

Boot process

Systemd primary task is to manage the boot process and provides informations about it.
To get the boot process duration, type:

# systemd-analyze
Startup finished in 422ms (kernel) + 2.722s (initrd) + 9.674s (userspace) = 12.820s

To get the time spent by each task during the boot process, type:

# systemd-analyze blame
7.029s network.service
2.241s plymouth-start.service
1.293s kdump.service
1.156s plymouth-quit-wait.service
1.048s firewalld.service
632ms postfix.service
621ms tuned.service
460ms iprupdate.service
446ms iprinit.service
344ms accounts-daemon.service
...
7ms systemd-update-utmp-runlevel.service
5ms systemd-random-seed.service
5ms sys-kernel-config.mount

To get the list of the dependencies, type:

# systemctl list-dependencies
default.target
├─abrt-ccpp.service
├─abrt-oops.service
...
├─tuned.service
├─basic.target
│ ├─firewalld.service
│ ├─microcode.service
...
├─getty.target
│ ├─getty@tty1.service
│ └─serial-getty@ttyS0.service
└─remote-fs.target

Journal analysis

In addition, Systemd handles the system event log, a syslog daemon is not mandatory any more.
To get the content of the Systemd journal, type:

# journalctl

To get all the events related to the crond process in the journal, type:

# journalctl /sbin/crond

Note: You can replace /sbin/crond by `which crond`.
To get all the events since the last boot, type:

# journalctl -b

To get all the events that appeared today in the journal, type:

# journalctl --since=today

To get all the events with a syslog priority of err, type:

# journalctl -p err

To get the 10 last events and wait for any new one (like “tail -f /var/log/messages“), type:

# journalctl -f

Control groups

Systemd organizes tasks in control groups. For example, all the processes started by an apache webserver will be in the same control group, CGI scripts included.
To get the full hierarchy of control groups, type:

# systemd-cgls
├─user.slice
│ └─user-1000.slice
│ └─session-1.scope
│ ├─2889 gdm-session-worker [pam/gdm-password]
│ ├─2899 /usr/bin/gnome-keyring-daemon --daemonize --login
│ ├─2901 gnome-session --session gnome-classic
. .
└─iprupdate.service
└─785 /sbin/iprupdate --daemon

To get the list of control group ordered by CPU, memory and disk I/O load, type:

# systemd-cgtop
Path Tasks %CPU Memory Input/s Output/s
/ 213 3.9 829.7M - -
/system.slice 1 - - - -
/system.slice/ModemManager.service 1 - - - -

To kill all the processes associated with an apache server (CGI scripts included), type:

# systemctl kill httpd

To put resource limits on a service (here 500 CPUShares), type:

# systemctl set-property httpd.service CPUShares=500

Note1: The change is written into the service unit file. Use the –runtime option to avoid this behavior.
Note2: By default, each service owns 1024 CPUShares. Nothing prevents you from giving a value smaller or bigger.
To get the current CPUShares service value, type:

# systemctl show -p CPUShares httpd.service

Service management

Systemd deals with all the aspects of the service management. The systemctl command replaces the chkconfig and the service commands. The old commands are now a link to the systemctl command.
To activate the NTP service at boot, type:

# systemctl enable ntpd

Note1: You should specify ntpd.service but by default the .service suffix will be added.
Note2: If you specify a path, the .mount suffix will be added.
Note3: If you mention a device, the .device suffix will be added.
To deactivate it, start it, stop it, restart it, reload it, type:

# systemctl disable ntpd
# systemctl start ntpd
# systemctl stop ntpd
# systemctl restart ntpd
# systemctl reload ntpd

Note: It is also possible to mask and unmask a service. Masking a service prevents it from being started manually or by another service.
To know if the NTP service is activated at boot, type:

# systemctl is-enabled ntpd
enabled

To know if the NTP service is running, type:

# systemctl is-active ntpd
inactive

To get the status of the NTP service, type:

# systemctl status ntpd
ntpd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

If you change a service configuration, you will need to reload it:

# systemctl daemon-reload

To get the list of all the units (services, mount points, devices) with their status and description, type:

# systemctl

To get a more readable list, type:

# systemctl list-unit-files

To get the list of services that failed at boot, type:

# systemctl --failed

To get the status of a process (here httpd) on a remote server (here rhel7.example.com), type:

# systemctl -H root@rhel7.example.com status httpd.service

Run levels

Systemd also deals with run levels. As everything is represented by files in Systemd, target files replace run levels.
To move to single user mode, type:

# systemctl rescue

To move to the level 3 (equivalent to the previous level 3), type:

# systemctl isolate runlevel3.target

Or:

# systemctl isolate multi-user.target

To move to the graphical level (equivalent to the previous level 5), type:

# systemctl isolate graphical.target

To set the default run level to non-graphical mode, type:

# systemctl set-default multi-user.target

To set the default run level to graphical mode, type:

# systemctl set-default graphical.target

To get the current default run level, type:

# systemctl get-default
graphical.target

To stop a server, type:

# systemctl poweroff

Note: You can still use the poweroff command, a link to the systemctl command has been created (the same thing is true for the halt and reboot commands).
To reboot a server, suspend it or put it into hibernation, type:

# systemctl reboot
# systemctl suspend
# systemctl hibernate

Linux standardization

Systemd‘s authors have decided to help Linux standardization among distributions. Through Systemd, changes happen in the localization of some configuration files.

Miscellaneous

To get the server hostnames, type:

# hostnamectl
Static hostname: rhel7.example.com
Icon name: computer-laptop
Chassis: laptop
Machine ID: bcdc71f1943f4d859aa37e54a422938d
Boot ID: f84556924b4e4bbf9c4a82fef4ac26d0
Operating System: Red Hat Enterprise Linux Everything 7.0 (Maipo)
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.0:beta:everything
Kernel: Linux 3.10.0-54.0.1.el7.x86_64
Architecture: x86_64

Note: There are three kinds of hostnames: static, pretty, and transient.
“The static host name is the traditional hostname, which can be chosen by the user, and is stored in the /etc/hostname file. The “transient” hostname is a dynamic host name maintained by the kernel. It is initialized to the static host name by default, whose value defaults to “localhost”. It can be changed by DHCP or mDNS at runtime. The pretty hostname is a free-form UTF8 host name for presentation to the user.” Source: RHEL 7 Networking Guide.
To assign the rhel7 hostname permanently to the server, type:

# hostnamectl set-hostname rhel7

Note: With this syntax all three hostnames (static, pretty, and transient) take the rhel7 value at the same time. However, it is possible to set the three hostnames separately by using the –pretty, –static, and –transient options.
To get the current locale, virtual console keymap and X11 layout, type:

# localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: en_US
X11 Layout: en_US

To assign the en_GB.utf8 value to the locale, type:

# localectl set-locale LANG=en_GB.utf8

To assign the en_GB value to the virtual console keymap, type:

# localectl set-keymap en_GB

To assign the en_GB value to the X11 layout, type:

# localectl set-x11-keymap en_GB

To get the current date and time, type:

# timedatectl
Local time: Fri 2014-01-24 22:34:05 CET
Universal time: Fri 2014-01-24 21:34:05 UTC
RTC time: Fri 2014-01-24 21:34:05
Timezone: Europe/Madrid (CET, +0100)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
Sun 2013-10-27 02:59:59 CEST
Sun 2013-10-27 02:00:00 CET
Next DST change: DST begins (the clock jumps one hour forward) at
Sun 2014-03-30 01:59:59 CET
Sun 2014-03-30 03:00:00 CEST

To set the current date, type:

# timedatectl set-time YYYY-MM-DD

To set the current time, type:

# timedatectl set-time HH:MM:SS

To get the list of time zones, type:

# timedatectl list-timezones

To change the time zone to America/New_York, type:

# timedatectl set-timezone America/New_York

To get the users’ list, type:

# loginctl list-users
UID USER
42 gdm
1000 tom
0 root

To get the list of all current user sessions, type:

# loginctl list-sessions
SESSION UID USER SEAT
1 1000 tom seat0

1 sessions listed.

To get the properties of the user tom, type:

# loginctl show-user tom
UID=1000
GID=1000
Name=tom
Timestamp=Fri 2014-01-24 21:53:43 CET
TimestampMonotonic=160754102
RuntimePath=/run/user/1000
Slice=user-1000.slice
Display=1
State=active
Sessions=1
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0

DMARC and the Email Authentication Process

DMARC is designed to fit into an organization's existing inbound email authentication process. The way it works is to help email receivers determine if the purported message "aligns" with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the "non-aligned" messages. For example, assuming that a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:

In the above example, testing for alignment according to DMARC is applied at the same point where ADSP would be applied in the flow. All other tests remain unaffected.

At a high level, DMARC is designed to satisfy the following requirements:

• Minimize false positives.
• Provide robust authentication reporting.
• Assert sender policy at receivers.
• Reduce successful phishing delivery.
• Work at Internet scale.
• Minimize complexity.

It is important to note that DMARC builds upon both the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications that are currently being developed within the IETF. DMARC is designed to replace ADSP by adding support for:

• wildcarding or subdomain policies,
• non-existent subdomains,
• slow rollout (e.g. percent experiments)
• SPF
• quarantining mail

Junos OS 13.3R5

New and Changed Features

This section describes the new features and enhancements to existing features in Junos OS Release 13.3R5 for the EX Series.

• Hardware
• Infrastructure
• Multicast
• Network Management and Monitoring
• OpenFlow

Hardware

• Extended cable manager for EX9214 switches—An extended cable manager is now available for EX9214 switches. The extended cable manager enables you to route cables away from the front of the line cards and Switch Fabric modules and provides easier access to the switch than the standard cable manager. To obtain the extended cable manager, order the MX960 Enhanced Cable Manager, ECM-MX960. (Note that installation of the extended cable manager must be done by a Juniper-authorized technician and that the service cost is in addition to the component cost.) 

Infrastructure

• Support for IPv6 for TACACS+ authentication (EX9200)—Starting with Release 13.3, Junos OS supports IPv6 along with the existing IPv4 support for user authentication using TACACS+ servers.

Multicast

• MLD snooping on EX9200 switches—EX9200 switches support Multicast Listener Discovery (MLD) snooping. MLD snooping constrains the flooding of IPv6 multicast traffic on VLANs on a switch. When MLD snooping is enabled on a VLAN, the switch examines MLD messages between hosts and multicast routers and learns which hosts are interested in receiving traffic for a multicast group. Based on what it learns, the switch then forwards multicast traffic only to those interfaces in the VLAN that are connected to interested receivers instead of flooding the traffic to all interfaces. You configure MLD snooping at either the [edit protocols] hierarchy level or the [edit routing-instances routing-instance-name protocols] hierarchy level. 

Network Management and Monitoring

• sFlow technology on EX9200 switches—EX9200 switches support sFlow technology, a monitoring technology for high-speed switched or routed networks. The sFlow monitoring technology randomly samples network packets and sends the samples to a monitoring station. You can configure sFlow technology on an EX9200 switch to continuously monitor traffic at wire speed on all interfaces simultaneously. The sFlow technology is configured at the [edit protocols sflow] hierarchy level. 

OpenFlow

Support for OpenFlow v1.0—Starting with Junos OS Release 13.3, EX9200 switches support OpenFlow v1.0. You use the OpenFlow remote controller to control traffic in an existing network by adding, deleting, and modifying flows on switches. You can configure one OpenFlow virtual switch and one active OpenFlow controller at the [edit protocols openflow] hierarchy level on each device running Junos OS that supports OpenFlow

Network Time Protocol Vulnerabilities

OVERVIEW

Google Security Team researchers Neel Mehta and Stephen Roettger have coordinated multiple vulnerabilities with CERT/CC concerning the Network Time Protocol (NTP). As NTP is widely used within operational Industrial Control Systems deployments, NCCIC/ICS-CERT is providing this information for US Critical Infrastructure asset owners and operators for awareness and to identify mitigations for affected devices. ICS-CERT may release updates as additional information becomes available.
These vulnerabilities could be exploited remotely. Exploits that target these vulnerabilities are publicly available.
Products using NTP service prior to NTP-4.2.8 are affected. No specific vendor is specified because this is an open source protocol.

IMPACT

Exploitation of these vulnerabilities could allow an attacker to execute arbitrary code with the privileges of the ntpd process.

Impact to individual organizations depends on many factors that are unique to each organization. ICS-CERT recommends that organizations evaluate the impact of this vulnerability based on their operational environment, architecture, and product implementation.

BACKGROUND

The NTP is described in RFC 958a, an open source collaboration for acceptance and is used to synchronize system time over a network.

VULNERABILITY CHARACTERIZATION

VULNERABILITY OVERVIEW

INSUFFICIENT ENTROPYb

If the authentication key is not set in the configuration file, ntpd will generate a weak random key with insufficient entropy.

This vulnerability was resolved with NTP-dev4.2.7p11 on January 28, 2010.

CVE-2014-9293c has been assigned by CERT/CC to this vulnerability. A CVSS v2 base score of 7.3 has been assigned by CERT/CC; the CVSS vector string is (AV:N/AC:L/Au:M/C:P/I:P/A:C).d

USE OF CRYPTOGRAPHICALLY WEAK PRNGe

Prior to NTP-4.2.7p230 ntp-keygen used a weak seed to prepare a random number generator. The random numbers produced were then used to generate symmetric keys.
This vulnerability was resolved with NTP-dev4.2.7p230 on November 1, 2010.
CVE-2014-9294f has been assigned by CERT/CC to this vulnerability. A CVSS v2 base score of 7.3 has been assigned; the CVSS vector string is (AV:N/AC:L/Au:M/C:P/I:P/A:C).g

STACK-BASED BUFFER OVERFLOWSh

A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. All NTP4 releases before 4.2.8 are vulnerable.
This vulnerability is resolved with NTP-stable4.2.8 on December 19, 2014.
CVE-2014-9295i has been assigned by CERT/CC to this vulnerability. A CVSS v2 base score of 7.3 has been assigned; the CVSS vector string is (AV:N/AC:L/Au:N/C:P/I:P/A:P).j

MISSING RETURN ON ERRORk

In the NTP code, a section of code is missing a return, and the resulting error indicates processing did not stop. This indicated a specific rare error occurred, which does not appear to affect system integrity. All NTP Version 4 releases before Version 4.2.8 are vulnerable.
This vulnerability is resolved with NTP-stable4.2.8 on December 19, 2014.
CVE-2014-9296l has been assigned by CERT/CC to this vulnerability. A CVSS v2 base score of 5.0 has been assigned; the CVSS vector string is (AV:N/AC:L/Au:N/C:N/I:N/A:P).m

VULNERABILITY DETAILS

EXPLOITABILITY

These vulnerabilities could be exploited remotely.

EXISTENCE OF EXPLOIT

Exploits that target these vulnerabilities are publicly available.

DIFFICULTY

An attacker with a low skill would be able to exploit these vulnerabilities.

MITIGATION

All NTP Version 4 releases, prior to Version 4.2.8, are vulnerable and need to be updated to Version 4.2.8.
ICS-CERT strongly encourages CIKR users to backup current operational ICS configurations, and thoroughly test the updated software for system compatibility on a test system before attempting deployment on operational systems.
CERT/CC has published a Vulnerability Note at the following URL:
http://www.kb.cert.org/vuls/id/852879
The latest NTP releases can be accessed at:
http://support.ntp.org/bin/view/Main/SoftwareDownloads.
ICS-CERT would like to thank NTP for coordinating with the Google Security Team Researchers.
ICS-CERT also encourages asset owners to take additional defensive measures to protect against this and other cybersecurity risks.

• Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
• Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
• When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

vCenter Server Appliance 5.5 vs vCenter Server 5.5

vCenter Server Appliance 5.5 vs vCenter Server 5.5 on Windows

vCenter Server Appliance 5.5 is reducing the dependency of Windows operating system for vCenter server Install. With VCSA 5.5 on Embedded database can manage 100 hosts and 3000 Virtual Machines. vCSA reduces lot of administrative efforts by reducing efforts needed for windows patching, software update and management of Guest OS on windows operating system. It is necessary to understand the difference between the vCenter Server Appliance 5.5 and vCenter server 5.5 installed on windows Server. This post will explain you the detailed difference between the 2 items.

Feature	vCenter Server Appliance 5.5	vCenter Server 5.5 on Windows
Can be Deployed	Only as a Virtual Machine	Can be installed on Physical or Virtual windows Machine
Operating System	Preconfigured Linux-based virtual machine	vCenter 5.5 requires 64 Bit OS and 64 bit DSN: Windows Server 2012 (64 bit) Windows Server 2008 Sp2 (64 bit) Windows Server 2008 R2 Sp1 (64 bit) Windows Server 2008 R2 (64 bit)
Database	PostgreSQL for the embedded database Supports Oracle Database	SQL Server 2005 (SP4) (Standard\Enterprise) (32-bit & 64-bit)SQL Server 2008 (R2 SP2, R2 SP1) (Express\standard\Enterprise\Datacenter) (32-bit & 64-bit) SQL Server 2012 (SP1) (Enterprise\Standard) (32-bit & 64-bit) Oracle 11 G Release 2 (Enterprise\Standard) & Oracle 11G ONE edition (32-bit & 64-bit)
Installation Method	Deployed as a Virtual Machine using OVF or OVA template	Need to install on top of Windows Operating System.
Hosts Per vCenter	100 Hosts with embedded vPostgres database 1000 Hosts with Oracle Database	1000 hosts per vCenter Server
Virtual Machines Per vCenter	3,000 VM’s with embedded vPostgres database 10,000 VM’s with Oracle Database	10,000 VM’s per vCenter Server
vCenter Linked Mode	Not Supported	Supported with Windows Install
vCenter Server Heartbeat	Not Supported	vCenter heartbeat is a windows application. It works with Windows install vCenter server
VMware Update Manager	You can’t install VUM on VCSA. Update Manager can be installed on separate windows machine to use with VCSA	Supported with Windows Install
AutoDeploy	Autodeploy is bundled with VCSA	Should be installed as an additional package. Installation files are located in vCenter Installation DVD
Syslog Collector	Syslog collector is installed by default	Should be installed as an additional package. Installation files are located in vCenter Installation DVD
ESXi Dump Collector Service	ESXi Dump Collector Service is installed by default	Should be installed as an additional package. Installation files are located in vCenter Installation DVD
vSphere Web Client	Pre-Installed with VCSA	Should be installed as an additional package. Installation files are located in vCenter Installation DVD
PowerCLI	Cannot be installed on vCSA	Can be installed on Windows vCenter Server machine
IPV6 support	IPv6 is not supported. Only supports IPV4	Both  IPv4 and IPv6 are supported

Release for CentOS Linux Rolling media

CentOS Linux rolling builds are point in time snapshot media rebuild
from original release time, to include all updates pushed to
mirror.centos.org's repositories. This includes all security, bugfix,
enhancement and general updates for CentOS Linux. Machines installed
from this media will have all these updates pre-included and will look
no different when compared with machines installed with older media
that have been yum updated to the same point in time. All rpm/yum
repos remain on mirror.centos.org with no changes in either layout or
content. 

We will aim to update and issue for release a new set of these files
at the end of every month going forward. Each released filename
includes a datestamp and a buildtag to indicate the content included.
Files marked as 20141129_02 indicate that it includes all content
released to mirror.centos.org upto ( and including ) the 29th of Nov
2014 and is the second build of that cycle. While all build's are made
public at buildlogs.centos.org/, only those that pass our QA and
testing cycles will be marked as released, to be included in
buildlogs.centos.org/rolling/. We will also do interim builds as
needed ( for development and testing purposes ) at different points in
time, those builds will not be marked for general release, but will
still be avilable publicly.

Since there is a need to test these images, the release will always
lag few days behind the datestamp ( and therefore content included )
in the release. My aim is to automate as much of this as possible
going forward to reduce this time lag as much as possible, however we
might not be able to remove it completely.

With every cycle, we hope to increase the content made available in
this rolling format. Immediate next steps include bringing the CentOS
Linux 7 livemedia into the rolling releases followed by CentOS Linux 6
content from the next ( December 2014 ) cycle.

Due to the way the installer works in CentOS-5, and its point in time
we have no plans on including CentOS-5 in this cycle at this point.

For the sake of uniformity and communication, the release media will
be referenced by the month it reflects, not the month it was released
in. Making this release the Nov 2014 Rolling release.

Other content formats like containers and vendor specific images will
aim to start with the same cycle as the main CentOS Linux media, but
might move to a more frequent build and release cycle if needed.
Special Interest Groups ( http://wiki.centos.org/SpecialInterestGroup
) wanting to do media and installer releases should also consider
using the rolling timelines to sync with.

CentOS Linux distro installer media:

File: CentOS-7-x86_64-DVD-20141129_02.iso
Sha256sum:
85a46c62b5bfc701678bef7854bb73af4ccfb840dfcbfb2f9b2189e08fe9438c

File: CentOS-7-x86_64-Everything-20141129_02.iso
Sha256sum:
f9fdd8b12c9529a1e3bf7628ebee964b2aeb9fd66540de7b369e0fde6f7a4236

File: CentOS-7-x86_64-Minimal-20141129_02.iso
Sha256sum:
e1338d13178f1c66c17386b7ced0b1459c677ff9a1cf095ac4db377234cc03fa

Symlinks are provided that will always map to the latest released
builds, as follows ( including their current mapping )
http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-DVD.iso
- -> CentOS-7-x86_64-DVD-20141129_02.iso
http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Everything.iso
- -> CentOS-7-x86_64-Everything-20141129_02.iso
http://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Minimal.iso
- -> CentOS-7-x86_64-Minimal-20141129_02.iso

These symlinks will be updated to point at the latest tested and
released media and make for a good target in automation that requires
CentOS Linux media.

Cloud and Instance Images:

The CentOS Linux 7 GenericCloud image is built to include cloud-init
from the Extras/ repository. The image is made available in multiple
formats, with identical content. The cloud images are released via
http://cloud.centos.org/centos/7/images/

File: CentOS-7-x86_64-GenericCloud-20141129_01.qcow2
Desc: is the reference image.
Size: 944 MB
Sha256Sum:
7710ffdd497cf00fc72c22a3fa7cc7adb3424d3542521ca8fbe19eba9ded403f

File: CentOS-7-x86_64-GenericCloud-20141129_01.qcow2c
Desc: This is the same image, run through the qemu qcow2 internal
compression setup - while this image is suiteable for development and
play, it comes with non trivial i/o performance penalties and
therefore not recommended for production.
Size: 399MB
Sha256Sum:
db42e4fb9565e75f0acbe6b54a5b8822f3f1e9783fb1a553e1552c72ceaff8df

File: CentOS-7-x86_64-GenericCloud-20141129_01.qcow2.xz
Desc:  This is the regular qcow2 file, run through the xz compression
tool. This gives a regular qcow2 file, suiteable for production use.
Size: 266MB
Sha256Sum:
9b0b38c48a24164c15c33625972b87835501b6994c3ee894f6b79ce40e7d5e54

File: CentOS-7-x86_64-GenericCloud-20141129_01.raw
Desc: This is a raw format file for systems that dont consume qcow2
image types. Its also suiteable to use with "qemu-img convert" to
render into different formats.
Size: 8GB.
Sha256Sum:
2e643310bdb3cda775905408dbfe378a5eed04e91db193165178afc5ed5492b8


Symlinks are provided that will always map to the latest released
builds, as follows ( including their current mapping )
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
- -> CentOS-7-x86_64-GenericCloud-20141129_01.qcow2
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c
- -> CentOS-7-x86_64-GenericCloud-20141129_01.qcow2c
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2.xz
- -> CentOS-7-x86_64-GenericCloud-20141129_01.qcow2.xz
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.raw
- -> CentOS-7-x86_64-GenericCloud-20141129_01.raw

These symlinks will be updated to point at the latest tested and
released media and make for a good target in automation that requires
CentOS Linux media.