Intermediate

See how it is possible to deploy and manage a large number of desktops in a private cloud using LTSP-Cluster. LTSP is the Linux Terminal Server Project. Using LTSP-Cluster enables you to deploy thousands of desktop in a scalable manner. You will be able to see and test yourself features that those Linux desktop offers using Thin or Fat Clients, such as 3D support, multimedia, 3D effects, and much more. You will also see remote access of the desktop in the Cloud, and support for Windows Terminal Server.

Amazon Web Services (AWS) Elastic Compute Cloud (EC2) provides on demand, self service, pay as you go computing infrastructure, including servers, storage, network, security, monitoring, load balancing, auto scaling, and more.

The focus of this presentation will be running Linux servers on EC2. The workshop will demonstrate using Ubuntu, but EC2 supports many Linux distros including Ubuntu, Debian, Fedora Core, CentOS, RHEL, Gentoo, and OpenSuse.

All you need to get started is a credit card to create an Amazon account. Expenses for the workshop should be under $0.25 (yes, that's a quarter). Attendees should create their Amazon accounts _before_ this session.

Controlling EC2 resources can be done using a browser on any operating system including Linux, Mac, or Windows. (The presenter's entire company runs on EC2, managed by employees with laptops.)

By the end of the workshop you will have an AWS account and a running Linux server, which we will promptly shut down before ending the class so that you will incur no further charges until you decide to use EC2 again in the future.

Cloud infrastructures have provided a great deal of power and versatility, but come at a cost of management overhead. In many cases, a node in a cloud infrastructure has no guarantee of being there at any given moment, has an indeterminable spin up time, and has no way of determining apriori where it will be. These make it hard to coordinate work across the nodes.

The typical approach for these setups is to provide an HTTP based registrar. While that works in many cases, the lack of bidirectional communication introduces a bit of ambiguity. What is happening between checkins? Does a node need to unregister itself? What happens when a node goes down?

Botnet shepherds have long been dealing with similar problems as cloud shepherds are dealing with now. A botnet node can go down at any time, there is no way to determine when a node will come into the botnet, and botnet nodes come from all over the place. Currently, the primary mechanism that botnet shepherds use to control their networks is over IRC channels. While the primary appeals have been the low barrier to entry, the always on messaging infrastructure, and the inability to lock down the channel, this approach provides an efficient way to coordinate activity in an environment with the above issue with little overhead.

Given the similarities between managing a botnet herd and managing a cloud herd, why not use the same management mechanisms that botnets use for more above the board purposes? How well do instant messaging infrastructures work for cloud infrastructures?

In this talk, we examine how we can use the botnet herding techniques to manage a large host of servers in a couple of scenarios. We will look at using XMPP as a transport mechanism for a traditional hosting environment as well as a cloud environment.

Making multimedia a success in thin client environments was no easy task … but there's a recipe. How do LTSP Local Apps work? Learn the inner workings of how Local Applications seamlessly operate between the LTSP client and server.

The following will be covered:
- explanation of plumbing on server and client side
- sshfs utilization
- how applications are integrated with Gnome menus.
- configuring access to server directories
- routing network traffic

Having worked at a couple of very large Linux installations (one of them having four thousand servers across three data centers, and one having about six hundred across two), and having built one of these environments completely from scratch, it becomes obvious very quickly that normal manual deployment processes, such as using a CDROM or other physical boot media, simply do not scale. Add to that configuration for different server roles and application deployment, it becomes obvious that an automated end-to-end deployment system becomes the only way forward.

This talk will cover creating and end-to-end deployment system with little to no manual intervention, using only open source tools. The open source tools involved are:

- RT/AT (Asset Tracker)

- nictool/djbdns

- dhcpd (and the pros and cons of using your own integration script)

- PXE/tftpboot

- kickstart

- puppet

- subversion

I will discuss how to turn these tools into a deployment system which will allow you, once configured, to quickly and easily set up as many servers at a time as you have SSH sessions available, and even ways to not have to use SSH sessions and kick the build off programmatically, using expect and other such tools, and to do so using different configuration and application profiles, all controlled from a central information source.

As part of our efforts to study botnets and their effect on Internets, we are booting millions of Linux kernels. To make this scale work, the Linux images must be small (16 MB or less). Observation is also an issue; even tiny information streams, scaled to 10 million, can be overwhelming. In this talk I will discuss our work and the systems we are using for the actual runs.

Written in ruby, PoolParty provides a nice domain specific language for describing a repeatable, declarative cloud computing infrastructure. Mainly focusing on amazon's EC2 offering, the presentation will cover basic concepts of cloud computing, how PoolParty works and how you can get into the clouds in one command.