news aggregator

Mark Shuttleworth: #8 – Ubuntu makes useful guarantees on every cloud

Planet Ubuntu - Sat, 2014-05-31 11:41

This is a series of posts on reasons to choose Ubuntu for your public or private cloud work & play.

When you see Ubuntu on a cloud it means that Canonical has a working relationship with that cloud vendor, and the Ubuntu images there come with a set of guarantees:

  1. Those images are up to date and secure.
  2. They have also been optimised on that cloud, both for performance and cost.
  3. The images provide a standard experience for app compatibility.

That turns out to be a lot of work for us to achieve, but it makes your life really easy.

Fresh, secure and tasty images

We update the cloud images across all clouds on a regular basis. Updating the image means that you have more of the latest updates pre-installed so launching a new machine is much faster – fewer updates to install on boot for a fully secured and patched machine.

  1. At least every two weeks, typically, if there are just a few small updates across the board to roll into the freshest image.
  2. Immediately if there is a significant security issue, so starting a fresh image guarantees you to have no known security gotchas.
  3. Sooner than usual if there are a lot of updates which would make launching and updating a machine slow.

Updates might include fixes to the kernel, or any of the packages we install by default in the “core” cloud images.

We also make sure that these updated images are used by default in any “quick launch” UI that the cloud provides, so you don’t have to go hunt for the right image identity. And there are automated tools that will tell you the ID for the current image of Ubuntu on your cloud of choice. So you can script “give me a fresh Ubuntu machine” for any cloud, trivially. It’s all very nice.

Optimised for your pocket and your workload

Every cloud behaves differently – both in terms of their architecture, and their economics. When we engage with the cloud operator we figure out how to ensure that Ubuntu is “optimal” on that cloud. Usually that means we figure out things like storage mechanisms (the classic example is S3 but we have to look at each cloud to see what they provide and how to take advantage of it) and ensure that data-heavy operations like system updates draw on those resources in the most cost-efficient manner. This way we try to ensure that using Ubuntu is a guarantee of the most cost-effective base OS experience on any given cloud.

In the case of more sophisticated clouds, we are digging in to kernel parameters and drivers to ensure that performance is first class. On Azure there is a LOT of deep engineering between Canonical and Microsoft to ensure that Ubuntu gets the best possible performance out of the Hyper-V substrate, and we are similarly engaged with other cloud operators and solution providers that use highly-specialised hypervisors, such as Joyent and VMware. Even the network can be tweaked for efficiency in a particular cloud environment once we know exactly how that cloud works under the covers. And we do that tweaking in the standard images so EVERYBODY benefits and you can take it for granted – if you’re using Ubuntu, it’s optimal.

The results of this work can be pretty astonishing. In the case of one cloud we reduced the Ubuntu startup time by 23x from what their team had done internally; not that they were ineffective, it’s just that we see things through the eyes of a large-scale cloud user and care about things that a single developer might not care about as much. When you’re doing something at scale, even small efficiencies add up to big numbers.

Standard, yummy

Before we had this program in place, every cloud vendor hacked their own Ubuntu images, and they were all slightly different in unpredictable ways. We all have our own favourite way of doing things, so if every cloud has a lead engineer who rigged the default Ubuntu the way they like it, end users have to figure out the differences the hard way, stubbing their toes on them. In some cases they had default user accounts with different behaviour, in others they had different default packages installed. EMACS, Vi, nginx, the usual tweaks. In a couple of cases there were problems with updates or security, and we realised that Ubuntu users would be much better off if we took responsibility for this and ensured that the name is an assurance of standard behaviour and quality across all clouds.

So now we have that, and if you see Ubuntu on a public cloud you can be sure it’s done to that standard, and we’re responsible. If it isn’t, please let us know and we’ll fix it for you.

That means that you can try out a new cloud really easily – your stuff should work exactly the same way with those images, and differences between the clouds will have been considered and abstracted in the base OS. We’ll have tweaked the network, kernel, storage, update mechanisms and a host of other details so that you don’t have to, we’ll have installed appropriate tools for that specific cloud, and we’ll have lined things up so that to the best of our ability none of those changes will break your apps, or updates. If you haven’t recently tried a new cloud, go ahead and kick the tires on the base Ubuntu images in two or three of them. They should all Just Work TM.

 

It’s frankly a lot of fun for us to work with the cloud operators – this is the frontline of large-scale systems engineering, and the guys driving architecture at public cloud providers are innovating like crazy but doing so in a highly competitive and operationally demanding environment. Our job in this case is to make sure that end-users don’t have to worry about how the base OS is tuned – it’s already tuned for them. We’re taking that to the next level in many cases by optimising workloads as well, in the form of Juju charms, so you can get whole clusters or scaled-out services that are tuned for each cloud as well. The goal is that you can create a cloud account and have complex scale-out infrastructure up and running in a few minutes. Devops, distilled.

Valorie Zimmerman: Exciting! Writing another KDE book: Frameworks in Randa

Planet Ubuntu - Sat, 2014-05-31 08:54

Returning to Randa is always tremendous, no matter what the work is. The house in Randa, Switzerland is so welcoming, so solid, yet modern and comfortable too.

KDE is in the building mode this year. If you think of the software like a house, Frameworks is the foundation and framing. Of course it isn't like a house, since the dwelling we are constructing is made from familiar materials, but remade in a interactive, modular fashion. I'd better stop with the house metaphor before I take it too far, because the rooms (applications) will be familiar, yet updated. And we can't call the Plasma Next "paint", yet the face KDE will be showing the world in our software will be familiar yet completely updated as well.

However, this year will see the foundation for KDE's newest surge ahead in software, from the foundation to the roof, to use the house metaphor one more time. I really cannot wait to get there and start work on our next book, the Framework Recipe book (working title). Of course, travel is expensive, and most of us will come from all over the world. So once again, we're raising funds for the Randa Meetings, which will be the largest so far. The e.V. is a major sponsor, but this is one big gathering. We need community support. Please give generously here:

www.kde.org/fundraisers/randameetings2014/index.php

Bryan Quigley: The Mozilla I want

Planet Ubuntu - Fri, 2014-05-30 21:13

Somewhat a response to
https://webwewant.mozilla.org/en/
https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
https://fsf.org/news/fsf-condemns-partnership-between-mozilla-and-adobe-to-support-digital-restrictions-management

NOTE: These are more personal opinions and not necessarily those of my employer, your employer, or any of the businesses and government in my town,city, state, country.

DRM

It is *never* something people want.  Have you ever heard someone say “I really want this content I bought/”rented” to be harder to share/remix/watch and to have even greater legal ramifications if I do so?”  They do want content made by Hollywood, but those are different things.

DRM – Mozilla being played?

This reminds me of the time Chrome said it would drop H264 [1].   From what played out in public it seemed that Mozilla didn’t see the need to push for H264 sooner because they trusted Google to actually drop H264 support.

In a somewhat reverse situation, Mozilla just said they will adopt EME in Firefox before any of the possible benefits are realized by others.  Right now it’s being implemented only in Chrome and IE 11 [2], and I’ve only seen it used in Chrome OS and IE 11.   From my point of view I would have preferred if Mozilla had at least waiting to see if we will get more platform support from major vendors on this.  (aka Linux support for Netflix)

If so, maybe the increase in Linux market-share would provide some balance to the DRM’s negative affects.  Making free software overall a net win.   If so, I would (still reluctantly) support Mozilla’s decision here if they saw it as an end to get Hollywood media to more freer platforms.   But why not wait and see if this is actually true with Google Chrome/Netflix on Linux?

[1] http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html
[2] http://html5test.com/compare/feature/video-drm.html

Reduce “Hollywood” power

I would like to see Mozilla pushing Indie/Crowdsourcing media, like:
Paid streaming site for indie videos https://indieflix.com/
Public broadcasting http://www.pbs.org/
Better publishing http://www.getmiro.com/
Basically, How can Mozilla use it’s capabilities to better change the media landscape?  (A slightly “better” form of DRM should not be the answer to this question).

Abandon the DoNoTrack header, provide actual options

It doesn’t work (and almost certainly never will) and it gives people a false sense of doing something.   You are giving advertisers another data point to track!  It literally does the opposite of what is supposed to.

Instead!

  •  Finish blocking 3rd party cookies (https://blog.mozilla.org/privacy/2013/02/25/firefox-getting-smarter-about-third-party-cookies/)
  • Promote (by adding it as a search option, etc) providers that promise to not track ANY of their users.   DuckDuckGo being the most obvious example.
    Their is so little difference between Yahoo and Bing search.. and DuckDuckGo is a damn good search engine[2].
  • Push advertisers off of Flash (generally a good idea, but also will help with privacy – no flash cookies, etc)
    Generally I’m supportive of the Click-to-play, etc initiatives Mozilla has taken thus far.  Flash is the exception to that rule.   Here’s the outline of a plan to push advertisers off of it. (the numbers are obviously made up for illustrative purposes)

    1. Start forcing Click-to-play for Flash when the site has more than 6 plugins running (pick some “high” number, and count all plugins, not just flash)
    2. Reduce the number of plugins to 5, after some number of Firefox releases or some specific Adobe Flash counting metric.  Repeat pushing to 4, etc.
    3. Once advertisers get on board and Flash ads aren’t served by the big advertisers, now we can push Flash to click-to-play at 2 instances per page.
    4. Once flash usage drops under 5% [1], we’d be able to push it to default click-to-play for all Flash.

[1] http://w3techs.com/technologies/details/cp-flash/all/all
[2] http://libretechtips.com/reviews-internet/duckduckgo-comparison-google-bing-yandex

SSL 3.0 – When will it go away?

You’ve removed the (easy) option to disable it.  When will it go away for good?  Why does Chrome let the user see what protocol version (TLS 1.2 vs 1.0, etc) their users are using, but Firefox doesn’t?

Mobile – Firefox OS

Well I work at a direct competitor in mobile… but not actually working with our phone product..

  • Launching just with Facebook contact sync well, isn’t very open and totally goes against promoting those that respect your same values.
  • I get that you can’t magically make the devices more open, but at least can we get public commitments for how long a device will be supported for?  And how often it will get Firefox OS updates?
  • I wish you had used Thunderbird as Firefox OS’s email client… I think that would let it scale really really well and give you a new reason to push features there.. Maybe you are under the hood?

If you’re reading this and don’t know, you can try out Firefox OS (“Boot2Gecko”) on your desktop too! (https://nightly.mozilla.org/)

End on a positive note..

I love the new Firefox interface.  It’s awesome and makes customizing the browser much better.   I’m a nightly user and teach courses on Firefox.  I’m not going anywhere (fast) over the DRM decision.  Going to keep doing what I do and see how it pans out…

Ronnie Tucker: Full Circle #85 hits the streets…

Planet Ubuntu - Fri, 2014-05-30 17:19

This month:
* Command & Conquer
* How-To : Python, LibreOffice, and GRUB2 Pt.1.
* Graphics : Blender and Inkscape.
* Review: Ubuntu 14.04
* Security Q&A
* What Is: CryptoCurrency
* Open Source Design
* NEW! - Arduino
plus: Q&A, Linux Labs, Ask The New Guy, Ubuntu Games, and a competition to win a Humble Bundle!

Get it while it’s hot!
http://fullcirclemagazine.org/issue-85/

Sam Hewitt: Hamburger Buns

Planet Ubuntu - Fri, 2014-05-30 16:00

If you're making hamburgers, buns are needed. You can buy them but they are dead simple to make yourself and (like most homemade bread) they're going to taste far superior to anything that comes off a shelf.

Just in case you wanted my basic (and perfect) hamburger mince recipe to:

Hamburger Recipe
    Ingredients

    4 hours of waiting; 10 minutes of work; Makes 8 buns

  • 3 cups all-purpose flour
  • 1 teaspoon salt
  • 1 (1/4 oz) package active dry yeast
  • 1 cup warm water
  • 1 large egg
  • 3 tablespoons butter, melted
  • 3 tablespoons sugar
  • 1 tablespoon milk
  • olive oil
  • 1 egg, beaten
  • 1 tablespoon sesame or poppy seeds, for garnish (optional)
    Directions
  1. Dissolve the yeast in the warm water with 1/4 of the flour. Let stand until quite foamy.
  2. Whisk together an egg, with the milk, butter & sugar.
  3. Dump the remaining flour and salt into a food processor (or stand mixer with a dough hook).
  4. Add the wet ingredients:
    • If using a food processor, slowly pour in the yeast mixture & the egg-milk mixture and blitz until the mixture comes together into a ball.
    • If using a stand mixer, add the yeast & egg-milk mixtures and run the machine on low for 5-6 minutes.
    If it sticky to the touch add a little more flour.
  5. Dump the dough-mass onto a lightly floured surface and form into a ball.
  6. Coat lightly with olive oil and place in a large bowl. Cover lightly with a towel and let rise until it has doubled in volume –about 2 hours.
  7. Transfer risen dough to a lightly floured surface, and flatten a bit to remove any large bubbles.
  8. Form into a large even circle and divide into 8 even pieces. Form each of those into a ball, flatten slightly and place onto a baking sheet lined with parchment paper.
  9. Lightly drape a sheet of plastic wrap over the buns and let rise again for another hour.
  10. Preheat the nearest oven to 375 degrees Fahrenheit (190 Celcius).
  11. Lightly brush all the buns with the beaten egg and sprinkle with sesame or poppy seeds, if using.
  12. Bake for 15-20 minutes until the exteriors are golden brown.
  13. Remove & let cool completely. Slice in half crosswise & serve.

Canonical Design Team: Making ubuntu.com responsive: adapting our navigation to small screens (9)

Planet Ubuntu - Fri, 2014-05-30 14:12

This post is part of the series ‘Making ubuntu.com responsive‘.

One of the biggest challenges when making the move to responsive was tackling the navigation in ubuntu.com. This included rethinking not only the main navigation with first, second and third level links, but also a big 3-tier footer and global navigation.

Desktop size main navigation and footer on ubuntu.com.

1. Brainstorming

Instead of assigning this task to a single UX designer, and with the availability of everyone in the team very tight, we gathered two designers and two UX designers in a room for a few hours for an intensive brainstorming session. The goal of the meeting was to find an initial solution for how our navigation could work in small screens.

We started by analysing examples of small screen navigation from other sites and discussing how they could work (or not) for ubuntu.com. This was a good way of generating ideas to solve the navigation for our specific case.

Some of the small screen navigation examples we analysed, from left to right: the Guardian, BBC and John Lewis.

We decided to keep to existing common design patterns for small screen navigation rather than trying to think of original solutions, so we stuck with the typical menu icon on the top right with a dropdown on click for the top level links.

Settling on a solution for second and third level navigation was trickier, as we wanted to keep a balance between exposing our content and making the site easy to navigate without the menus getting in the way.

We thought keeping to simple patterns would make it easier for users to understand the mechanics of the navigation quickly, and assumed that in smaller screens users tend to forgive extra clicks if that means simpler and uncluttered navigation.

Some of the ideas we sketched during the brainstorming session.

2. Prototyping

With little time on our hands, we decided we’d deliver our solution in paper sketches for a prototype to be created by our developers. The starting point for the styling of the navigation should follow closely that of Ubuntu Insights, and the remaining tweaks should be built and designed directly in code.

Navigation of Ubuntu Insights on large and small screens.

We briefed Ant with the sketches and some design and UX direction and he quickly built a prototype of the main navigation and footer for us to test and further improve.

First navigation prototype.

3. Improving

We gathered again to test and review the prototype once it was ready, and suggest improvements.

Everyone agreed that the mechanics of the navigation were right, and that visual tweaks could make it easier to understand, providing the user with more cues about the hierarchy of the content.

Initially, when scaling down the screen the search and navigation overlapped a small amount before the small screen menu icon kicked in, so we also thought it would be nice to animate the change of the amount of padding between widths.

We also made sure that if JavaScript is not available, when the user clicks on the menu icon the page scrolls down to the footer, where the navigation is accessible.

Final navigation prototype, after some tweaks.

Some final thoughts

When time is of essence, but you still want to be able to experiment and generate as many ideas as possible, spending a couple of hours in a room with other team members, talking through case studies and how they can be applied to your situation proved a really useful and quick way to advance the project. And time and time again, it has proved very useful to invite people who are not directly involved with the project to give the team valuable new ideas and insights.

We’re now planning to test the navigation in our next quarterly set of usability testing, which will surely provide us with useful feedback to make the website easier to navigate across all screen sizes.

Reading list

Valorie Zimmerman: Thank you, Jerry Seinfeld

Planet Ubuntu - Fri, 2014-05-30 06:45
Seinfeld has a stand-up routine about how your party self wants to be wild and crazy, because the person who will suffer the hangover is "Morning Guy." This was how I thought and why I procrastinated for most of my life. Eventually I figured out that my Self today and my Self tomorrow -- same Self.

I value kindness, and try to be kind and thoughtful to others. So why not be kind to my Self too? In my effort to make life more peaceful and happy, I've gradually started to be kinder to my future self, and have reduced procrastination quite a bit. Along the way, I've discovered how much easier it is to just do a small task when I notice it needs doing, rather than putting it off. My attitude about those little tasks has changed too, and they hardly seem like work. Instead, they feel like being kind to my Self.

This all seems like a virtuous circle, since doing small tasks immediately keeps life simple and clean, and living in a clean, calm environment makes it easier to do the work to keep things up. This seems to be valuable everywhere; in the daily schedule, around the house, at work, in relationships.

Perhaps it was easier to fall into this way of working since I've been started some practices like making cold-brew coffee and fermented foods, both of which need to be started hours or days before they are ready to consume. Every time I finish preparing a new batch, I feel like I'm 'paying it forward' to my future self. The work we've been doing on our house also helps in a major way.

For those who call this kindness "selfishness," consider the so-called Golden Rule, restated by Jesus as love your neighbor as you love yourself. That final phrase says it all; self-care is at the core of love.

And it all counts.

  • Making your bed when you get up, counts.
  • Brushing and flossing your teeth, counts.
  • Eating breakfast, counts.
  • Washing up, counts.
  • Making a meeting on time, counts.
  • Writing a thoughtful email, counts.
  • Helping someone in IRC, counts.
  • Eating vegetables or fruit instead of junk food, counts.
  • Drinking water instead of a sugary beverage, counts.
  • Walking up a flight of stairs instead of taking the elevator, counts.
  • Picking up a bit of trash, counts.
  • Getting to bed in time to have a full night's sleep, counts.
  • Writing a blog post, counts!

Anyone who has flown in a jetliner, has heard the advice: If you are traveling with someone, and the oxygen masks drop, do not help them put on their masks first. Put on your own mask, then help others!

Many of the ideas that have helped me get to this place come from unfuckyourhabitat.tumblr.com which is invaluable. It is one thing to give yourself credit for the progress you make, but it is amazing to have a team of people cheering you on!

Jeremy Kerr: Netbooting with petitboot

Planet Ubuntu - Fri, 2014-05-30 01:12

I've been working on petitboot's netboot code recently. Here's the lowdown on how it all works.

Essentially, everything is intended to be compatible with the de-facto standard pxelinux behaviour. However, there's one major difference, in that we skip the stage where the machine downloads a binary pxelinux loader (because we're already running the loader, right?). This means that you probably don't want to populate the filename field in the DHCP response header. That said, petitboot should work fine with most current pxelinux configurations.

Netboot configuration process

By default, petitboot will send a DHCP request on any interfaces that have an active link (ie, have a network cable plugged-in). The DHCP response will dictate petiboot's behaviour:

Firstly, petitboot will look for a "PXE configuration file" option (DHCP option 209) in the response. If this is specified, then petitboot will download and parse that configuration file. This can be either a full URL, or a file path. See the URLs section below for details on paths and URLs.

If no explicit configuration file is given (ie, there's no option 209 included in the DHCP response), then petitboot will attempt pxelinux-style configuration auto-discovery, using the machine's MAC address, the IP of the DHCP lease, and fall back to a file named default. For example, for a machine with a MAC of 00:01:02:03:04:05, given a lease IP of 192.168.0.10 (C0A8000A in hex), petitboot will request the following files, in order, stopping at the first successful download:

  1. prefix/pxelinux.cfg/01-00-01-02-03-04-05
  2. prefix/pxelinux.cfg/C0A8000A
  3. prefix/pxelinux.cfg/C0A8000
  4. prefix/pxelinux.cfg/C0A800
  5. prefix/pxelinux.cfg/C0A80
  6. prefix/pxelinux.cfg/C0A8
  7. prefix/pxelinux.cfg/C0A
  8. prefix/pxelinux.cfg/C0
  9. prefix/pxelinux.cfg/C
  10. prefix/pxelinux.cfg/default

- where prefix will depend on a few things:

  1. If the DHCP response include a "PXE path prefix" option (DHCP option 210), petitboot will use that value as the prefix. This prefix can be a full URL, or just a path prefix (see the URLs section for details). Note that option 210 should always end with a trailing slash.
  2. Otherwise, TFTP is assumed, the server is determined from the DHCP response, and the files are requested from the top-level directory.

Finally, if there is a "file" parameter present in the DHCP header, then that file is added as a binary boot option, to be executed directly by the machine with no initrd or boot arguments. Don't specify a text config file in this manner, it won't work.

Configuration files

Petitboot supports configuration files based on the syslinux configuration format. However, not all keywords are parsed, as some relate to functionality that isn't relevant in a petitboot environment. Currently, petitboot supports the DEFAULT, KERNEL, INITRD and APPEND keywords. Keywords are case-insensitive.

Here's a typical petitboot configuration file that defines a single, default boot option:

default Linux 3.10.4 label Linux 3.10.4 kernel tftp://boot-server/powerpc/vmlinux-3.10.4 initrd tftp://boot-server/powerpc/initrd-3.10.4 append root=/dev/sda1 console=hvc0 URLs, servers and paths

Remote resources ­— such as configuration files, kernels and initramfs images — can be specified as full URLs (eg. tftp://hostname/path/file) or just paths (eg. /path/file). If a full URL is given, then petitboot will use that as-is. Supported protocols are currently http, ftp, tftp and nfs.

If only a path is given, petitboot will assume the TFTP protocol, and use an appropriate server address based on the DHCP response parameters, in this order:

  1. The "TFTP Server name" option - DCHP option 66
  2. The "Server Identifier" option - DHCP option 54
  3. The "siaddr" field in the DHCP/BOOTP header

Within a configuration file, paths are resolved relative to the location of that file. In keeping with the pxelinux configuration format, absolute paths can be give with a :: prefix - eg. ::/powerpc/vmlinux. Full URLs are always treated as absolute.

DHCP configuration examples

Here are a couple of DHCP server configurations that illustrate how to netboot petitboot machines. These examples are intended for the ISC DHCP server, and only show the configurations relevant to petitboot configuration - you'll need to define the usual subnet, range, etc sections too.

Single, predefined configuration file

This simple example configures all DHCP clients to use a single petitboot configuration file, served over HTTP:

# define a "conf-file" option syntax for the PXE configuration file (opt 209) option conf-file code 209 = text; option conf-file "http://boot-server/petitboot.cfg"; Fixed configuration for multiple architectures

This example shows a configuration that will allow petitboot-based POWER machines to work alongside pxelinux-based x86 machines. We use the DHCP architecture identifier 0x0e to dinstinguish the POWER OPAL boot clients.

# define a "conf-file" option syntax for the PXE configuration file (opt 209) option conf-file code 209 = text; # define an "arch" option syntax for the DHCP architecture identifier (opt 93) option arch code 93 = unsigned integer 16; # specify separate configuration files for powerpc & x86 machines # and configure x86 machines to use the pxelinux.0 loader. if option arch = 00:0e { option conf-file "powerpc/pxelinux/netboot.cfg"; } else { filename "x86/pxelinux/pxelinux.0"; option conf-file "netboot.cfg"; }

Since we're not specifying full URLs for the configuration files here, petitboot will attempt to download using TFTP, from the same host as the DHCP server.

In the x86 section, note that the config file (netboot.cfg) is specified relative to the pxelinux.0 binary. In this case, pxelinux will request the file from x86/pxelinux/netboot.cfg.

Managed TFTP server

In automated-provisioning environments, a central deployment system may control machine setup and boot. When a newly-racked machine is first booted, we want it to boot to an initial install/provision environment, where it is initialised and registers itself with the provisioning service. Once that registration is complete, we want it to boot to the newly-installed environment.

One way to achieve this is to have the deployment system manage PXE configuration files that are served over TFTP.

For this, we'd rely on the PXE autodiscovery mechanism for any newly-deployed machines (relying on the fallback to the configuration file named 'default'). Once a machine has completed its provisioning process (and registered with the deployment service), a per-machine configuration file can be added to the TFTP server, named after the machine's MAC address. This file will configure the newly-provisioned machine to boot to its standard OS environment, rather than booting through the initial-install process again.

For this scenario, we can use a PXE path prefix parameter to distinguish machines of different architectures:

# define a "path-prefix" option syntax for the PXE path prefix (opt 210) option path-prefix code 210 = text; # define an "arch" option syntax for the DHCP architecture identifier (opt 93) option arch code 93 = unsigned integer 16; # use 192.168.0.3 as our managed TFTP server next-server 192.168.0.3; # provide separate binaries and configuration files depending on # client architecture if option arch = 00:0e { # POWER OPAL option path-prefix "powerpc/"; } else if option arch = 00:07 { # x86-64 EFI option path-prefix "x86-efi/"; filename "pxelinux/bootx64.efi"; } else { # x86 PC-BIOS option path-prefix "x86-pc-bios/"; filename "pxelinux/pxelinux.0"; }

We could just as easily use HTTP instead of TFTP here, by specifying full HTTP URLs as the configuration files. For the non-petitboot machines, we'd need to use a pxe loader that supports HTTP, like gPXE.

Managed DHCP server

This is similar to the previous example, but rather than using per-machine configuration files (served over TFTP), we can implement per-machine configuration directly in the DHCP server configuration.

If our DHCP configuration is managed by the deployment system, we can use host-specific configurations for machines that have been provisioned, and fall back to a default configuration for newly-racked machines. In this scenario, the deployment system is responsible for managing the DHCP configuration by adding a 'host' stanza for each known machine, after installation.

# define a "conf-file" option syntax for the PXE configuration file (opt 209) option conf-file code 209 = text; # define an "arch" option syntax for the DHCP architecture identifier (opt 93) option arch code 93 = unsigned integer 16; # configuration for running installers on unknown hosts: provide separate # binaries and configuration files depending on client architecture if option arch = 00:0e { # POWER OPAL option conf-file "pxe-configs/installer-powerpc.conf" } else if option arch = 00:07 { # x86-64 EFI option conf-file "pxe-configs/installer-x86-64-efi.conf" filename "pxelinux/bootx64.efi"; } # known host configurations, for which we specify an existing config file. These # sections are generated and managed by the deployment process, after each # machine has been provisioned. host server-001 { hardware ethernet 3c:97:0e:3b:85:00; option conf-file "pxe-configs/runtime-powerpc.conf"; } host server-002 { hardware ethernet b4:1e:26:c4:a0:be; option conf-file "pxe-configs/runtime-x86.conf"; }

Pages

Subscribe to Free Software Magazine aggregator