VMware vSphere 5.5 Cookbook

<span><span><p>A task-oriented guide with over 150 practical recipes to install, configure, and manage VMware vSphere components</p><li><p>Explore the use of command line interface (CLI) to consistently configure the environment and automate it reasonably</p></li><li><p>Discover the best practices to deploy stateless and statefull ESXi hosts and upgrade them</p></li><li><p>Simplified and to-the-point theory to manage vSphere Storage and Networking Environment</p></li><p><b>In Detail</b></p><p>VMware is still the undisputed leader in providing virtualization solutions ranging from server virtualization to storage and network virtualization. VMware vSphere is the industry's most complete and robust virtualization platform, transforming data centers into dramatically simplified cloud infrastructures.</p><p>VMware vSphere 5.5 Cookbook will walk you through the procedures involved in installing or upgrading your current vSphere environment to Version 5.5 and also help you perform the most common administration tasks ranging from configuring HA, DRS, and DPM, configuring storage and networking, to patching/upgrading using vSphere Update Manager, performing remote CLI operations using VMA, and monitoring the performance of a vSphere environment.</p><p>This book is written with simplified and to-the-point theory eliminating the need for lengthy reading before performing a task. Most of the tasks are accompanied with relevant screenshots and flowcharts to facilitate your understanding.</p><p>Downloading the example code for this book <a href="You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com.">You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com.</a> <a href="If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.">If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.</a></p></span></span>

PowerCLI Cookbook

<span><span><p>Over 75 step-by-step recipes to put PowerCLI into action for efficient administration of your virtual environment</p><li><p>Solve complex problems in vSphere by creating custom PowerCLI routines that can be accessed with simple native commands</p></li><li><p>Explore specific use cases for PowerCLI that illustrate methods that can apply to other situations and problems encountered in vSphere</p></li><li><p>Step-by-step instructions to create scripts to automate repetitive tasks in vSphere using predefined PowerCLI commands</p></li><p><b>In Detail</b></p><p>PowerCLI allows faster administration by executing tasks on groups of objects in the virtual environment and is flexible enough to allow complex, scripted routines to solve complex problems.</p><p>PowerCLI Cookbook illustrates the ease of performing repetitive tasks using native PowerCLI commands to speed up administration. This book teaches you how to create custom functions and modules to solve specific problems and deploy these solutions to operators. It covers all vSphere administration areas including host, cluster, and virtual machine management utilizing PowerCLI.</p><p>Finally, this book will enable administrators to execute scripts that will open new possibilities for automation and also enable them to manage VM workloads effectively.</p><p>Downloading the example code for this book <a href="You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com.">You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com.</a> <a href="If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.">If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.</a></p></span></span>

ownCloud 8.1 coming in June

8.1 release coming
With the release of ownCloud 8.0 we made some changes to our release cycle. We would move to time based releases every three months. With the focus of the 8.1 release on stability and performance and to align our schedule better to holiday periods, we’ve decided it was prudent to lengthen the stabilization period of our first release in this new cycle with one month, easing our transition and maintaining the highest possible quality.

Focus for 8.1

Those of you following our semi-regular development updates have already noticed the emphasis placed on stability, security and architectural improvements in ownCloud development for this release. While there have been plenty of incremental improvements, much more time has been spent on improving existing functionality than on introducing new.

Adding an extra month to focus on bug fixing will help make sure this ownCloud release is the most stable ever – of course, this also depends on the testing that is done. If you want to be sure that the upcoming ownCloud release is fully ready for your use case – with your specific hardware, software, settings and usage – make sure you test it and report any problems you find! After all, problems our developers do not know about can hardly be fixed.

Your input in testing is paramount to ensure the stability and suitability of ownCloud 8.1 for you!

Get involved in testing here.

Release Cadence

In our new release cycle, we plan one month for getting features merged and two to stabilize before release. This is similar to how the Linux kernel development works. You can develop on features all the time, and put them in a pull request in GitHub so they can be reviewed. We focus on reviewing, finishing up and merging open pull requests during the first month of a new release cycle and focus on testing, integration and refinement of the whole in the next two months.

By delaying our schedule by one month, the ownCloud 8.3 release will fall in the first week of December. We will then start development for 9.0, which we stabilize over January and February. As December is usually a less active month, we will have a more restricted set of changes that get merged – but it is better that the ‘quiet time’ is in the merging period than in the time we’re working to integrate, test and stabilize the release! The delay helps us ensure a better quality for the ownCloud 9.0 release.

If you’re interested in how ownCloud is developed, read a bit more about it here and check out the contribute page if you want to get involved in improving ownCloud – in any area you like. To keep up with what is going on, read our semi-regular development updates.

First release in the new cycle

So, there you have it. ownCloud 8.1 will be released in the beginning of June with 8.2 coming beginning of September, shortly after the ownCloud Contributor Conference in Berlin.

If you want to make sure this ownCloud release is as close to perfect as you need it to be, make sure to get involved in testing. And if there are features you’d like to get in, get them ready before June so they can be merged!

Edit: A lot of testing is taking place and it was decided to merge a few large but important structural improvements (good example), taking more time: release is now planned beginning of July!

On OpenSSH and Logjam – Technology & Policy

Recent work showing the feasibility of calculating discrete logarithms on large integers has put the Diffie-Hellman key exchange parameters we use every day in the spotlight. I have looked at what this means for SSH key exchange. In short, on your SSH server, do the following:

awk '{ if ($5 <= 2000) printf "#"; print }' /etc/ssh/moduli > /tmp/large_moduli
mv /tmp/large_moduli /etc/ssh/moduli

And put the following in your sshd_config:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
              ecdh-sha2-nistp384,ecdh-sha2-nistp521,
              diffie-hellman-group14-sha1,
              diffie-hellman-group-exchange-sha1,
              diffie-hellman-group-exchange-sha256

Note that curve25519-sha256@libssh.org is only supported in OpenSSH 6.5 and up, and only works reliably in OpenSSH 6.7 and up. On your SSH client, put the following in your ssh_config:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
              ecdh-sha2-nistp384,ecdh-sha2-nistp521,
              diffie-hellman-group14-sha1

If with this configuration you are unable to connect to some SSH servers, and you need to add diffie-hellman-group-exchange-sha1 or diffie-hellman-group-exchange-sha256 to the supported list of algorithms, you should recompile your SSH client with a DH_GRP_MIN of 2048, so that a server can’t force your client to use a weak group.

Technical details

Now follows a detailed explanation of these recommendations. The following key exchange mechanisms are supported in the current version (6.8) of OpenSSH:

  • curve25519-sha256@libssh.org
  • ecdh-sha2-nistp256
  • ecdh-sha2-nistp384
  • ecdh-sha2-nistp521
  • diffie-hellman-group1-sha1
  • diffie-hellman-group14-sha1
  • diffie-hellman-group-exchange-sha1
  • diffie-hellman-group-exchange-sha256

The first four mechanisms, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, do not use prime-field Diffie-Hellman and are not affected. Previous work shows that these mechanisms are much faster when used at the same security level, so you should use them!

The diffie-hellman-group1-sha1 mechanism uses the fixed 1024-bit Oakley Group 2 (not the 768-bit group 1, as the name of the mechanism might suggest). This group is within the range of being a viable target for nation-state attackers, and should not be used.

The diffie-hellman-group14-sha1 mechanism uses the fixed 2048-bit Oakley Group 14, which should be secure enough for now.

The diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256 mechanisms let the client and server negotiate a custom DH group. The client sends a tuple «min, n, max» to the server, indicating the client’s minimum, preferred and maximum group size. According to the RFC,

Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.

The OpenSSH server selects a suitable group from a pre-generated set of groups, installed system-wide in /etc/ssh/moduli (falling back to /etc/ssh/primes), using the choose_dh function in dh.c. In case no suitable group is found, the code defaults to Oakley Group 14, which is safe. A pre-generated set is distributed with the OpenSSH source and many binary distributions and is infrequently changed. The group sizes distributed with OpenSSH are 1024, 1536, 2048, 3072, 4096, 6144, and 8192 bits, with about 30 groups per size. The OpenSSH-distributed 1024-bit groups are well-known and within the range of being a viable target for nation-state attackers, and as such should not be used.

It is possible to generate your own set of groups, in which case it would be safer to use a 1024-bit group, but you might as well go for larger groups. The ssh-keygen man page mentions that “It is important that … both ends of a connection share common moduli.” That statement should not be interpreted as “both server and client need to have the same moduli configured”, as the server sends the chosen modulus to the client. As a case-in-point, the OpenSSH client does not access the system-wide moduli file at all during connection setup.

Speaking about the client, it usually offers the RFC-specified minimum of 1024 bits. There is nothing preventing a server from using that value and offering a well-known (and thus weak) group. So, a standard client shouldn’t use the custom group key exchange mechanisms, unless there is a way to change the minimum group size.