Fedora 19 New Features : NFStest

 NFStest provides a set of tools for testing either the NFS client or the NFS server, included tests focused mainly on testing the client.

 Test utilities package

Provides a set of tools for testing either the NFS client or the NFS server, most of the functionality is focused mainly on testing the client. These tools include the following:

• Process command line arguments
• Provide functionality for PASS/FAIL
• Provide test grouping functionality
• Provide multiple client support
• Logging mechanism
• Debug info control
• Mount/Unmount control
• Create files/directories
• Provide mechanism to start a packet trace
• Provide mechanism to simulate a network partition
• Support for pNFS testing

Installation

Install the rpm as root

# rpm -i NFStest-1.0.1-1.noarch.rpm

All manual pages are available

$ man nfstest

Run tests:

$ nfstest_pnfs --help

Untar the tarball

$ cd ~

$ tar -zxvf NFStest-1.0.1.tar.gz

The tests can run without installation, just set the python path

environment variable:

$ export PYTHONPATH=~/NFStest-1.0.1

$ cd NFStest-1.0.1/test

$ ./nfstest_pnfs --help

Or install to standard python site-packages and executable directories:

$ cd ~/NFStest-1.0.1

$ sudo python setup.py install

All manual pages are available

$ man nfstest

Run tests:

$ nfstest_pnfs --help

Clone the git repository

$ cd ~

$ git clone git://git.linux-nfs.org/projects/mora/nfstest.git

The tests can run without installation, just set the python path

environment variable:

$ export PYTHONPATH=~/nfstest

$ cd nfstest/test

$ ./nfstest_pnfs --help

Or install to standard python site-packages and executable directories:

$ cd ~/nfstest

$ sudo python setup.py install

All manual pages are available

$ man nfstest

Run tests:

$ nfstest_pnfs --help

Setup

Make sure user running the tests can run commands using 'sudo' without the need for a password.
Make sure user running the tests can run commands remotely using 'ssh' without the need for a password. This is only needed for tests which require multiple clients.
Create the mount point specified by the --mtpoint (default: /mnt/t) option on all the clients:

$ sudo mkdir /mnt/t

$ sudo chmod 777 /mnt/t

Examples

nfstest_pnfs

The only required option is --server

$ nfstest_pnfs --server 192.168.0.11

nfstest_cache

Required options are --server and --client

$ nfstest_cache --server 192.168.0.11 --client 192.168.0.20

Testing with different values of --acmin and --acmax (this takes a long time)

$ nfstest_cache --server 192.168.0.11 --client 192.168.0.20 --acmin 10,20 --acmax 20,30,60,80

nfstest_delegation

The only required option is --server but only the basic delegation tests will

be run. In order to run the recall tests the --client option must be used

$ nfstest_delegation --server 192.168.0.11 --client 192.168.0.20

nfstest_dio

The only required option is --server

$ nfstest_dio --server 192.168.0.11

nfstest_posix

The only required option is --server

$ nfstest_posix --server 192.168.0.11

RedHat Enterprise Virtualization 3.2 release

Red Hat Enterprise Virtualization 3.2 is designed to meet an increasing industry need for open virtualization solutions without compromising performance, scalability, security or features. Red Hat Enterprise Virtualization is also an essential component of Red Hat Cloud Infrastructure, which combines traditional datacenter virtualization features provided by Red Hat Enterprise Virtualization, cloud-enabled infrastructure provided by Red Hat OpenStack, and hybrid cloud management provided by Red Hat CloudForms, to deliver a comprehensive open hybrid cloud solution for customers seeking to adopt cloud-enabled applications and infrastructure in coexistence with their traditional infrastructure and migrate over time as their needs demand.

Red Hat Enterprise Virtualization 3.2 brings a vast array of new features, including:

• Fully supported Storage Live Migration, allowing virtual machine images to be moved from one storage domain to another without disrupting service;
• Support for the latest industry-standard processors from Intel and AMD, including Intel Haswell series and AMD Opteron G5 processors; and
• Enhancements in storage management, networking management, fencing and power management, Spice console enhancements, logging and monitoring, and more.

New Third-Party Plug-ins
A key feature in Red Hat Enterprise Virtualization 3.2 is the availability of a new third-party plug-in framework. Developed through community and vendor collaboration and contributions, the plug-in framework enables third parties to integrate new features and actions directly into the Red Hat Enterprise Virtualization management user interface. New menu items, panes, and dialog boxes allow users to access the new functionality the same way they use Red Hat Enterprise Virtualization's native functionality. The framework continues to evolve based on vendor and community requests, and any vendor may choose to consume the plug-in framework and add unique functionality to Red Hat Enterprise Virtualization.

Red Hat is already collaborating with several industry leaders to integrate their solutions with Red Hat Enterprise Virtualization via the new plug-in, including high availability and disaster recovery solutions from NetApp, Symantec, and Insight Control from HP:

• NetApp: Virtual Storage Console (VSC) for Red Hat Enterprise Virtualization helps improve efficiency while reducing cost and complexity in virtual environments using NetApp storage. VSC provides integrated virtual storage management, including rapid domain provisioning and cloning of hundreds of virtual machines, while enabling Red Hat administrators to access and execute all of these capabilities using the standard Red Hat Enterprise Virtualization management interface NetApp is now accepting applications for the VSC for Red Hat Enterprise Virtualization beta.

• Symantec: Veritas Cluster Server from Symantec, the comprehensive disaster recovery and high availability solution, will support Red Hat Enterprise Virtualization 3.2 environments. Once integration is complete, Veritas Cluster Server will offer "push button" disaster recovery orchestration, and together with the Veritas Operations Manager Recovery Plan feature completely automate the failover of a Red Hat Enterprise Virtualization environment over to a disaster recovery site. This includes guests, guest network reconfiguration, and storage reconfiguration. Veritas Cluster Server is designed to provide high availability and disaster recovery for databases, custom applications, and complete multi-tiered applications across physical and virtual environments over any distance.

• HP: Insight Control for Red Hat Enterprise Virtualization, a new plug-in currently being developed by HP to enable deployments using HP ProLiant servers to view a wealth of information provided by the HP Insight Control platform. Within the Red Hat Enterprise Virtualization graphical interface, administrators can quickly and easily obtain detailed information on the health of the HP server hardware.

Samba 4 as AD Server.

ENVIRONMENT
-----------------------
The new server runs CentOS6, version 6.3, 64-bit, minimal install with
current updates applied.
Samba4 version 4.0.0beta5
BIND version 9.8.2

INSTALLATION
----------------------
I was disappointed to say the least when I discovered that the Samba4
package included with RHEL/CentOS is basically an empty shell.  Even
though it's still at beta release, RH could have built it and put it in
the EPEL repo.  Or even the folks at CentOS could have added it to their
centosplus or extras repo.

Although I am capable, the thought of building Samba4 from source did
not excite me.  And it's a maintenance nightmare for upgrades.  With
some searching I found that the nice people at SOGo have built Samba4
for several distributions, including RPMs for RHEL/CentOS.  I believe
it's required for their OpenChange groupware product.  The Samba4 RPM is
now in their main repo and can be easily installed via yum.  See their
website (www.sogo.nu) for instructions.

# yum install samba4

This required only one dependency on my system - perl-Parse-Yapp.
I therefore commenced the Samba4 HowTo at step 4 (provisioning).

EXAMPLE
---------------
For this example I will assume a domain name of DEMO, AD domain
demo.local, server IP 192.168.0.1.

DNS
------
Setup /etc/resolv.conf to work correctly:
  domain demo.local
  nameserver 192.168.0.1
or
  search demo.local demo.com
  nameserver 192.168.0.1
if using multiple domains.

Because of the AD interaction with DNS it is important to have BIND
installed and working before attempting Samba4. But do NOT create a zone
file for the demo.local AD domain.  This will be done by the Samba4 DLZ
backend.  I initially setup zone files for demo.com, demo.local and a
reverse zone.  The demo.local zone file clashed with Samba4 so I removed
it.

PROVISIONING
-----------------------
To provision Samba4:
# provision --realm=demo.local --domain=DEMO --adminpass=secret
--server-role=dc --host-ip=192.168.0.1
I have IP aliases setup for virtual hosting so I specify here which
address I want to use (just in case).  Provision worked OK.
The following lines were added to /etc/named.conf as per the
instructions:
  tkey-gssapi-keytab "/var/lib/samba4/private/dns.keytab"
  include "/var/lib/samba4/private/named.conf"
The kerberos file was copies to /etc:
# cp /var/lib/samba4/private/krb5.conf /etc/
replacing the default (cp will keep the correct SELinux file context)

BEFORE STARTUP
-----------------------------
Before starting Samba4 you should be aware that you will have multiple
problems with iptables and SELinux, so turn them off for now.  More on
this later.  Stop iptables and set SELinux to permissive mode.
# service iptables stop
# setenforce 0

STARTING SAMBA
----------------------------
The first problem I found when trying to start Samba4 was the init
script - it doesn't work.  The script tries to start smbd, but somewhere
in the development the name was changed to samba, but script was never
updated.  There were other aspects of the script I didn't like either so
I rewrote the init script as follows:
---***---
#! /bin/bash
#
# samba4        This shell script takes care of starting and stopping 
#               the Samba4 server
#
# chkconfig: - 91 35
# description: Samba provides file and print services to SMB/CIFS
clients. \
#              Version 4 adds an Active Directory domain controller.
# config: /etc/samba4/smb.conf
# config: /etc/sysconfig/samba4
# pidfile: /var/rum/samba4/samba.pid
#
### BEGIN INIT INFO
# Provides: 
# Should-Start: 
# Short-Description: Start and stop the Samba4 server
# Description: Samba provides file and print services to SMB/CIFS
clients.
#              Version 4 adds an Active Directory domain controller.
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions
 
if [ -f /etc/sysconfig/samba4 ]; then
    . /etc/sysconfig/samba4
fi

# Avoid using root's TMPDIR
unset TMPDIR

prog=samba4
samba=/usr/sbin/samba
pidfile=/var/run/samba4/samba.pid
smbdpidfile=/var/run/samba4/smbd.pid

# Check that smb.conf exists.
[ -f /etc/samba4/smb.conf ] || exit 6

RETVAL=0

start() {
    echo -n $"Starting $prog: "
    daemon --pidfile=$pidfile $samba $SMBDOPTIONS
    RETVAL=$?
    echo
    return $RETVAL
}

stop() {
    echo -n $"Shutting down $prog: "
    killproc -p $pidfile $samba
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f $pidfile && rm -f $smbdpidfile
    return $RETVAL
}

# See how we were called.
case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    status)
        status -p $pidfile $samba
        RETVAL=$?
        ;;
    restart|reload)
        stop
        sleep 1
        start
        ;;
    *)
        echo $"Usage: $0 {start|stop|restart|status}"
        exit 1
esac

exit $RETVAL
---***---

The next problem was the permissions on the /var/lib/samba4/private
directory.  This is created as owner root:root mode 0700, as you would
expect with Samba3.  However, Samba4 puts AD domain files under here,
but BIND cannot access them because of the permissions.  Changing the
owner to root:named mode 0750 fixes this issue.
# chgrp named /var/lib/samba4/private
# chmod g+rx /var/lib/samba4/private

Restart BIND and start Samba4:
# service named restart
# service samba4 start
Both should startup successfully.

TESTING
-------------
I tested my Samba4 server using a Windows 7 VM.  I was able to join the
demo.local domain, then login as DEMO\Administrator.  Success!
I installed the RSAT tools for Windows 7 and enabled the AD DS snap-in
tools, Group Policy tools and DNS server tools.  This provides just
about everything needed to manage the AD domain - Users and Computers,
Group Policy Manager, DNS Manager - all done from a Windows client using
the native Windows tools.  Very cool!
I created a dummy user account and a couple of GPOs for roaming profiles
and folder redirection, and tested those with the user account.  It is
important to mention here that, after creating shares for the user
profiles and home directories and defining them in smb.conf, browse
those top-level shares in Windows as Administrator and add to the
security properties the group Domain Users with read/write access. 
Otherwise the user will not be able to write to them.
Note: I created the user home directory share as /home/DEMO to segregate
from unix users.

IPv6
------
Despite setting IPv6 to NO in the network script, netstat will still
show everything listening on IPv6 addresses.  Honestly, why can't RH
provide one simple setting to turn IPv6 off globally?  To disable this
nuisance for Samba add this to smb.conf and restart Samba4.
  interfaces = 127.0.0.1 192.168.0.1
  bind interfaces only = yes

AD DNS
------------
When using the DNS Manager to add new entries to the demo.local domain I
noticed something peculiar.  The SOA record, created by the provision
step, had the default TTL=0.  Therefore, any records created will
inherit this.  According to MS AD documentation this should be 3600. 
Attempts to change this from DNS Manager failed.  Is this a bug?  I then
attempted to change it using samba-tool, but this seems to be rather
broken, as it just spat out errors.  And the help is far from helpful. 
I eventually found that I can use nsupdate (part of BIND), but requests
to update the AD domain must be authenticated by kerberos (using kinit).
 To do this, install the krb5-workstation package.
# yum install krb5-workstation
# kinit Administrator
Password for Administrator@DEMO.LOCAL: secret
Update the existing records by adding them again with new values.
# nsupdate -g
> update add demo.local 3600 SOA server.demo.local hostmaster.demo.local  900 600 86400 3600
> update add demo.local 3600 NS server.demo.local
> update add demo.local 3600 A 192.168.0.1
> update add server.demo.local 3600 A 192.168.0.1
> send
Note that I successfully used the DNS Manager to add other A, CNAME and
MX records to demo.local.

NTP
------
I decided to build a local RPM with updated NTP to support signed ntp
required for AD clients.  I created the build user and environment
(plenty of info available on how to do this) and installed rpm-build,
gcc and make, with any dependencies.
# yum install rpm-build gcc make

I downloaded the ntp-4.2.4p8 SRPM from CentOS and ntp-4.2.6p5 tarball
from ntp.org, installed the SRPM and put the new tarball under SOURCES. 
The only edits I made to the ntp.spec file were:
- Update version/release numbers
- Comment out all patch lines
- Add --enable-ntp-signd after --enable-linuxcaps
- Add %{_sbindir}/sntp after %{_ntptime}
The HowTo had some other edits related to man8 but I ignored those
because they didn't seem right to me.

Run the build (not as root!):
$ rpmbuild -ba ntp.spec
This initially produced some errors, as expected, for required
dependencies.  I installed those packages, but removed them later to
keep the system clean (yum history undo is great for this).  The build
ran successfully, producing RPMs for ntp and ntpdate to install,
upgrading the existing 4.2.4 versions.
# yum install ./ntp-4.2.6* ./ntpdate-4.2.6*
I then edited the /etc/ntp.conf file as follows and restarted ntpd:
  restrict 192.168.0.0 mask 255.255.255.0 mssntp
  ntpsigndsocket /var/run/samba4/ntp_signd/
  
The Windows 7 client should now sync its clock to the DC.  From Windows
7 run:
C:> w32tm /resync /rediscover
This should report successful completion.  If not check:
C:> w32tm /query /configuration
The time provider should be type NT5DS.  If not try:
C:> w32tm /config /syncfromflags:domhier /update
C:> net stop w32time && net start w32time
When it's working the command
C:> w32tm /monitor
will report on the time source of the DC.

Initially my Windows 7 VM would not sync.  I believe the problem was,
before joining the domain, the VM had 192.168.0.1 set as an additional
time source.  After joining a domain this option is no longer visible,
but the setting is still trapped somewhere.  Searching the registry did
not help.  In the end I removed the VM from the domain, which made the
additional time source option visible again, deleted the setting that
was still there, then join the domain again.  After that it worked.

I will also mention that I read comments saying that the ownership and
mode of the ntp_signd directory had to be changed to give ntpd write
access.  I tried this and I disagree.  In fact, if you play with the
permissions Samba4 will refuse to create the socket.  The error is
clearly shown in the /var/log/samba4/samba.log file.  Samba4 creates the
ntp_signd directory as root:root 0755 and this works.

AVAHI
----------
I read in a couple of places that Avahi can be used as a replacement for
nmbd, which is currently missing in Samba4.  I installed avahi:
# yum install avahi
A couple of dependencies were required.  I created the file
/etc/avahi/services/samba.service as per examples with port 139 and
started the service.  But my Windows 7 VM will not see the server when
browsing the network.  If I run avahi-browse from the server it reports
the MS Windows network demo.local with server.demo.local at 192.168.0.1
as might be expected.  I am not sure why this does not work.  Maybe
someone has the answer to this.

IPTABLES
---------------
With the Samba4 server and Windows 7 client running it's time to try
enabling the security features again.  I read a number websites listing
port requirements for AD/Samba4 and not one them was complete and
correct.  This list is produced from netstat and by using Wireshark to
monitor the traffic.  To use netstat run:
# netstat -lntup | grep -e samba -e smbd

The ports needed are:
53, TCP & UDP (DNS)
88, TCP & UDP (Kerberos authentication)
135, TCP (MS RPC)
137, UDP (NetBIOS name service)
138, UDP (NetBIOS datagram service)
139, TCP (NetBIOS session service)
389, TCP & UDP (LDAP)
445, TCP (MS-DS AD)
464, TCP & UDP (Kerberos change/set password)
1024, TCP (this is a strange one but AD is using it)

Add these to iptables:
# iptables -A INPUT -p tcp --dport 53 -j ACCEPT
# iptables -A INPUT -p udp --dport 53 -j ACCEPT
# iptables -A INPUT -p udp --dport 137:138 -j ACCEPT
# iptables -A INPUT -p tcp --dport 139 -j ACCEPT
# iptables -A INPUT -p tcp --dport 445 -j ACCEPT
# iptables -A INPUT -p tcp --dport 135 -j ACCEPT
# iptables -A INPUT -p tcp --dport 88 -j ACCEPT
# iptables -A INPUT -p udp --dport 88 -j ACCEPT
# iptables -A INPUT -p tcp --dport 464 -j ACCEPT
# iptables -A INPUT -p tcp --dport 389 -j ACCEPT
# iptables -A INPUT -p udp --dport 389 -j ACCEPT
# iptables -A INPUT -p tcp --dport 1024 -j ACCEPT

Start the service and save the changes
# service iptables save
# service iptables start

SELINUX
-------------
Although I am experienced with unix/linux I had not used SELinux before
setting up this server.  I knew that it's a pain, but I wanted to
persevere with it, so I did a lot of reading to learn how to use it. 
However, in my opinion, the people who manage SELinux really need to do
something to improve its useability and administration because,
honestly, it's awful.  It's little wonder that many administrators just
turn it off.  And making GUI tools is not the answer.  Administrators
will not (and should not) install a desktop like Gnome on a server, so
the GUI tools are unavailable.

The problem with Samba4 and SELinux is that SELinux has no pre-defined
policy at this time for Samba4.  So I started out to make one.  With
SELinux in permissive mode it's allowing Samba4 to run but recording all
the things it doesn't like in the audit.log file.  To examine this log I
installed the policycoreutils-python tools package and its dependencies:
# yum install policycoreutils-python

To get a list of events run
# aureport -a
and for more detailed messages
# ausearch -m avc
Piping the messages through audit2allow generates a list of rules that
would allow the actions.  The initial results seemed a bit overwhelming.
 To produce something more reasonable I decided to utilise the file
contexts defined in the Samba3 policy as a basis and apply them to the
Samba4 installation.  To list these contexts:
# semanage fcontext -l | grep -e samba -e smbd

I modified these to suit the Samba4 installation and defined a set of
rules to relabel the Samba4 directories acordingly.  These are applied
as follows:
# semanage fcontext -a -t samba_initrc_exec_t
"/etc/rc\.d/init\.d/samba4"
# semanage fcontext -a -t samba_etc_t "/etc/samba4(/.*)?"
# semanage fcontext -a -t samba_var_t "/var/lib/samba4(/.*)?"
# semanage fcontext -a -t named_var_run_t
"/var/lib/samba4/private/dns(/.*)?"
# semanage fcontext -a -t named_conf_t
"/var/lib/samba4/private/named.conf.*"
# semanage fcontext -a -t named_conf_t
"/var/lib/samba4/private/dns.keytab"
# semanage fcontext -a -t samba_unconfined_script_exec_t
"/var/lib/samba4/sysvol/[^/]*/scripts(/.*)?"
# semanage fcontext -a -t winbind_var_run_t
"/var/lib/samba4/winbindd_privileged(/.*)?"
# semanage fcontext -a -t samba_log_t "/var/log/samba4(/.*)?"
# semanage fcontext -a -t smbd_var_run_t "/var/lock/samba4(/.*)?"
# semanage fcontext -a -t smbd_var_run_t "/var/run/samba4(/.*)?"
# semanage fcontext -a -t ntpd_var_run_t
"/var/run/samba4/ntp_signd(/.*)?"
# semanage fcontext -a -t winbind_var_run_t
"/var/run/samba4/winbindd(/.*)?"
# semanage fcontext -a -t winbind_var_run_t
"/var/run/samba4/winbindd_privileged(/.*)?"
Then apply the new contexts:
# restorecon -v /etc/rc.d/init.d/samba4
# restorecon -R -v /etc/samba4
# restorecon -R -v /var/lib/samba4
# restorecon -R -v /var/log/samba4
# restorecon -R -v /var/lock/samba4
# restorecon -R -v /var/run/samba4

Locally defined file contexts are stored in
/etc/selinux/targeted/contexts/files/file_contexts.local but this file
cannot be edited by hand.  Be aware that the order these are entered IS
important.  With pre-defined policies SELinux will apply the rules in a
logical order with more specific rules taking preference over less
specific ones.  This is not the case with locally created rules.  They
are applied sequentially as they are entered, so if the order is wrong
you get the wrong result.  That means having to delete some or all of
the rules and enter them again in the correct order.  I actually created
a script to do this tedious task.

With the new file contexts in place I allowed SELinux to gather log data
for a while, then used audit2allow to produce a file for generating a
policy module
# ausearch -m avc -ts dd/mm/yy | audit2allow -m samba4local >
samba4local.te
I edited the samba4local.te file to remove the unwanted commentary.  The
result looked like this:
---***---
module samba4local 1.0;

require {
    type initrc_t;
    type named_t;
    type named_var_run_t;
    type ntpd_t;
    type ntpd_var_run_t;
    type smbd_t;
    type samba_unconfined_script_exec_t;
    type urandom_device_t;
    type var_lock_t;
    class unix_stream_socket connectto;
    class unix_dgram_socket sendto;
    class sock_file write;
    class chr_file write;
    class file { read write getattr open lock };
    class dir { read search };
}

#============= named_t ==============
allow named_t urandom_device_t:chr_file write;

#============= ntpd_t ==============
allow ntpd_t initrc_t:unix_stream_socket connectto;
allow ntpd_t ntpd_var_run_t:sock_file write;

#============= smbd_t ==============
allow smbd_t initrc_t:unix_dgram_socket sendto;
allow smbd_t initrc_t:unix_stream_socket connectto;
allow smbd_t named_var_run_t:file { read write getattr open lock };
allow smbd_t samba_unconfined_script_exec_t:dir read;
allow smbd_t urandom_device_t:chr_file write;
allow smbd_t var_lock_t:dir search;
---***---

Compile the module and create the policy package:
# checkmodule -M -m -o samba4local.mod samba4local.te
# semodule_package -o samba4local.pp -m samba4local.mod
Load the module:
# semodule -i samba4local.pp

With this policy in place SELinux should be able to run in enforcing
mode without affecting Samba.
I also enabled the following SELinux booleans:
# setsebool -P samba_domain_controller on
# setsebool -P samba_enable_home_dirs on

DATA DEDUPLICATION

Data deduplication technology has gained rapid acceptance in the IT industry over the past several years for its ability to dramatically reduce the amount of backup data stored byeliminating redundant data. In its simplest terms, datadeduplication maximizes storage utilization while allowingorganizations to retain more backup data on disk for longer periods of time. This tremendously improves the efficiency ofdisk-based backup, lowering storage costs and changing theway data is protected. 

 

Although data deduplication solutions vary in terms of howdeduplication is accomplished, in general, data deduplicationworks by comparing new data with existing data from previous backup or archiving jobs, and eliminating there dundancies. Because only unique blocks are transferred,replication bandwidth requirements are reduced.

Debian GNU/Hurd 2013 release.

It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2013. This is a snapshot of Debian "sid" at the time of the Debian "wheezy" release (May 2013), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release.

The installation ISO images can be downloaded from Debian Ports in the usual three Debian flavors: NETINST, CD, DVD. Besides the friendly Debian installer, a pre-installed disk image is also available, making it even easier to try Debian GNU/Hurd.

Debian GNU/Hurd is currently available for the i386 architecture with more than 10.000 software packages available (more than 75% of the Debian archive, and more to come!).

Virtualization

The virtualization layer is implemented by the VMM and is software that runs in a layer between the VMkernel and one or more VMs. It provides the VM abstraction to the guest operating systems.

It is through the VMM that the VM leverages key technologies in the VMkernel. The VMM is part of the VMkernel and is provided for each VM.

The vSphere VMM manages CPU, memory, and input/output, or I/O, device virtualization by implementing software virtualization, hardware virtualization, or paravirtualization techniques.

Software virtualization is an approach in which the hypervisor uses binary translation technology to provide virtualization of CPU and memory for the guest operating systems.

Hardware virtualization is a technique in which hardware capabilities of current CPUs are exploited to provide virtualization of CPU and memory.

Paravirtualization is a virtualization approach that exports a modified hardware abstraction that requires operating systems to be explicitly modified and ported to run. VMware uses paravirtualization to optimize the performance of certain drivers, for example, Small Computer Systems Interface, or SCSI, and network drivers.

New Features in Linux Kernel 3.9

Ten weeks to the day after the arrival of version 3.8, Linux creator Linus Torvalds on Monday released version 3.9 of the Linux kernel.
“This week has been very quiet, which makes me much more comfortable doing the final 3.9 release, so I guess the last -rc8 ended up working,” wrote Torvalds in the announcement email early Monday. “Because not only aren't there very many commits here, even the ones that made it really are tiny and not pretty obscure and not very interesting.”

Linus Torvalds on Monday released version 3.9 of the Linux kernel.

That's certainly not to say that this new kernel release doesn't include a number of interesting features overall, however – quite the contrary, in fact. Here's a quick look at some of the highlights. 1. SSD Caching
It's always nice to see new features that enable faster performance, and one such example is Linux 3.9's addition of a device mapper target (dm-cache) that enables the use of speedy devices such as solid-state drives (SSDs) as a cache for slower devices such as rotating hard disks.  “Different 'policy' plugins can be used to change the algorithms used to select which blocks are promoted, demoted, cleaned etc.,” explains the changelog on KernelNewbies.org. “It supports writeback and writethrough modes.”
2. Expanded Architecture Support
Broadened support is another change that's pretty much always welcome, and Linux 3.9 actually adds two new architectures to the list of those supported. Specifically, this new release brings the Linux kernel port to the ARC700 processor family (750D and 770D) from Synopsys as well as the Meta ATP (Meta 1) and HTP (Meta 2) processor cores from Imagination. Meta cores can be found in many digital radios, while the ARC700 family is commonly embedded in SoCs in TV set-top boxes and digital media players.
3. Better Power Efficiency
Thanks to the inclusion of the Intel PowerClamp driver, which performs synchronized idle injection across all online CPUs, Linux 3.9 also offers improved power efficiency in terms of performance per watt.
4. Chromebook Support
Particularly useful for Chromebook owners yearning to get their favorite distro up and running on their machine, meanwhile, is that Linux 3.9 adds full support for “all the devices present in the Chrome laptops sold by many companies,” as KernelNewbies puts it.
5. Another Boost for ARM
Linux's support for ARM has improved considerably over the past few releases, and kernel 3.9 brings a key improvement in the form of support for the KVM virtualization system in the ARM architecture port. As KernelNewbies notes, “this brings virtualization capabilities to the Linux ARM ecosystem.”
6. Android Developer Support
Finally, targeting Android developers this time, Linux 3.9 adds support for the “Goldfish” virtualized platform that's part of the Android development environment. Essentially, that means it's now possible to develop for Android with “out-of-the-box” kernels.