Re: [Oneiric-Topic] Revisit Xen support
On Sat, Apr 2, 2011 at 5:03 PM, Clint Byrum wrote: > Noted. It sounds like Xen has a lot of inertia. I'd say big companies have a lot of inertia. Once they have chosen to invest in a technology, be it Xen or KVM, they build systems on this technology for years, hire experts (and get their employees to become experts), and they're not willing to reconsider their position a few months after (or even years) after just because the trend has changed. Xen was the state-of-the-art not so long ago, and it's already taken these big companies long enough to use it. KVM is the medium-to-long term future for many still. > I feel like there is a lot of anecdotal evidence, but we shouldn't make > our decisions just because somebody says KVM can't do this or Xen can > do that. I think many would agree that with current hardware and a brand new DC, it's generally a better idea to invest in KVM than Xen. But if we want Ubuntu to be an enterprise class OS for servers, that means we need to provide the tools for people to be conservative if they want to, and not to have to rethink the technology they've been successfully using for years. So, encouring the use of KVM, I'm all for it ; supporting the people who still need to use Xen and would like to do so with Ubuntu, that's also a major point if you want Ubuntu to be a reference in DCs. Nowadays, who would use inetd to implement a network service if they have xinetd at hand? I guess not many people. But we're not going to remove inetd from Ubuntu, because a lot of old services still use it and it's a standard per se, whether we use it for internal Ubuntu development or not. Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Oneiric-Topic] Monitoring plugin for byobu
Hi there, There is one byobu plugin I've been using in production for a few years now that I think could be very useful to more people: monitoring support. Like it or not, your servers are more likely to break when you're hacking on them. You could keep an eye on monitoring (or let it page you) every time you touch a server, but I don't know a lot of people who do that, and so often you find out you've broken the service after you've logged out. For this reason, on quite a few of my production machines, I've added a monitoring plugin to byobu, which retrieves the general status of the machine in the monitoring system (BB4/Hobbit in our case) as well as the status of each probe. The general status is displayed in the hardstatus with a background color corresponding to the general status of the machine in monitoring. Whenever something goes wrong, the general color changes in the hardstatus, and the problematic probes show up with their names and proper colors in the caption. This has saved me tons of times on many occasions, since I see the breakage in my shell session, even as I'm logged on the machine. Ubuntu doesn't provide Hobbit by default, so my plugin is not usable as it is, but maybe it could be nice to do a munin plugin for example, which would call munin on localhost (munin is very easy to probe that way) and provide a little monitoring interface in byobu. Your thoughts? Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Revisit Xen support
On Sat, Apr 2, 2011 at 1:51 AM, Clint Byrum wrote: > Excerpts from Chuck Short's message of Wed Mar 30 07:27:50 -0700 2011: >> Hi, >> >> In the past Xen support in Ubuntu as a host has been difficult for a >> variety of reasons most notably no upstream kernel support. Now that >> dom0 should be coming into the vanilla kernel soon. I think its time to >> revisit supporting Xen as a hypervisor as well. > > Just playing devil's advocate here. > > Other than people already having familiarity with Xen, what is a > compelling reason to support it in favor of, or in addition to, KVM? Familiarity is a good reason I think, but also industry standards, and hardware considerations. I think a lot of big companies expect major distributions such as Ubuntu to provide a proper support for such a standard as Xen. I know it came as a disappointment for us that using Lucid as a (production) Xen dom0 was nearly impossible. Also, afair, KVM requires hardware support. Most recent machines provide it, but it's not rare to find servers that are too old to use it, and then you'd rather use Xen for servers than VMWare... Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Ubuntu Orchestra
On Wed, Mar 30, 2011 at 6:51 PM, Dustin Kirkland wrote: > A series of similarly themed blueprints from UDS-Natty in Orlando were > subsequently combined into a single blueprint [1] in the Natty cycle. > > As of 11.04, we have several of the key building blocks now packaged > in the Ubuntu archive (cobbler, mcollective, etc). And we have a > branch at lp:orchestra that provides the basic meta packaging for > pieces we want to implement using the best of free software: > * Provisioning / Installation Services > * Configuration Management > * Monitoring > * Orchestration > > There are several limitations to stock ISO-based installs (eg, another > thread here raises the issue of the limited ISO capacity). A complete > network installation service is essential to the future of Ubuntu > Server efforts. I envision a situation where the first step in > deploying a set of Ubuntu Servers is to install the Ubuntu Orchestra > Provisioning server (apt-get install > ubuntu-orchestra-provisioning-server, or perhaps run a temporary > deploy server from a LiveUSB). Subsequent installations in the > hundreds or thousands are rapidly and flexibly bootstrapped directly > from the provisioning server. One thing I like about FAI is that (afair from a few years back at least) the live CD uses FAI to install the FAI server itself, using a special class. All the same, when setting up a puppetmaster, it's often recommended to begin with the puppetmaster class itself, ensuring that the machine can install/replicate/manage itself before it begins installing/replicating/managing others. I think it could be good to have an install CD specifically tailored for bootstrapping a provisioning server. After all, that's the only CD you might ever have to use to get started with your DC. > Our OpenStack integration efforts for 11.10 will require some > installation modifications similar to what we did in 9.10 for > Eucalyptus and UEC. Rather than hacking through the guts of the > debian-installer again for this work, I suggest that we build > OpenStack's installation on top of a modern network installation > service, as serious cloud deployments necessarily require the > installation of more than one system. (Note that OpenStack already > has a prototype of such a service with the Crowbar project.) As a note from working in a DC with complex network infrastructure, it could be useful (but maybe it's not Ubuntu's job) to provide a layout to control switches. In our infrastructure, we use VLANs extensively to organize services in sub-networks. We have an installation VLAN that is not routed and is reserved for machines to be installed via FAI. I know we're not the only ones doing this, and I believe it's generally a good practice, since it ensures that your installation DHCPd will not mess up production machines, and at the same time you won't have to play with cables either, just retag the switch port to use a production VLAN (or more than one if necessary) instead of the installation VLAN. In such infrastructures, it is useful to consider that the network installation service (or orchestra-like service) might control switches via SNMP to automatize this step. So the steps are: 1) Set switch port assigned to machine to installation VLAN; 2) Start network installation (reboot and let pxe + cobbler/FAI/kickstart/other do its job); 3) Set switch port assigned to machine to production VLAN; 4) Let puppet/cfengine/chef/other deploy software and configure the machine for production. I don't expect that Orchestra would impose a VLAN-based network infrastructure, but maybe it would be great if it provided functionalities to plug this kind of DC architecture directly in it. We could consider having such a functionality, and letting people plug in the SNMP mib they need for their router. Just an idea, but I think it might make a huge difference for big DCs. And sorry for the noise if that's already implemented :-) > A web/network-based installation service would allow the Ubuntu Server > to modernize its interface and handle far more installation modes and > workloads than an 80x25 teletype terminal can deliver. It would give > the Server Team the ability to integrate new software stacks such as > OpenStack easily within a single Ubuntu development cycle, something > that's simply not possible when integral debian-installer changes are > required (the tasksel menu is the only hook really at our disposal > right now). The combination of dynamically generated preseed > configurations coupled with config-management based post installation > handling would provide a modern, DevOps-style interface to Ubuntu > Server installations, and is key to our future. A web-base service is nice and user-friendly; I'm all for that. But I don't think it should replace the console tools, or implement functionalities that the CLI tools don't have. Sometimes you need to go to machine room, log in to your network installation server and do things manu
Re: [Oneiric-Topic] Revisit Xen support
On Wed, Mar 30, 2011 at 4:27 PM, Chuck Short wrote: > Hi, > > In the past Xen support in Ubuntu as a host has been difficult for a > variety of reasons most notably no upstream kernel support. Now that > dom0 should be coming into the vanilla kernel soon. I think its time to > revisit supporting Xen as a hypervisor as well. This is great news. Where I work, we had considered using Lucid as a dom0 but it was just a mess, and we did not want to consider KVM, so we ended up using CentOS dom0 (and even then, we got stuck with 2.6.18 kernels until recently, which was a big issue for Lucid and up domUs). I'll all for an officiel support for Ubuntu dom0, especially if it's vanilla! Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Byobu
> I have a prototype (based on an old version of byobu) on [0], which Missing the link, sorry: https://code.launchpad.net/~raphink/byobu/acl Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Augeas Integration
On Fri, Apr 1, 2011 at 5:03 PM, Scott Kitterman wrote: > I don't think any policy changes are needed. I think providing a lense and > Recommending or Depending on Augeas is sufficient. I don't read "provide a > program" as meaning the actual code is required to live in the relevant > package. > Right. Some providing a library that allows to modify the conffile would be fine, too. > I agree with the concept. I think that we need to move forward on something > like this in coordination with Debian (at leasts on the goals and technology). > Ubuntu may choose to implement aspects of this before Debian does, but no > matter which distro is ahead at any given time, I think it's essential that > both be on the same road. I completely agree. I am not a DD so it's much easier for me to implement that in Debian, but I would certainly not like to diverge on this subject, all the more that it has no reason to be Ubuntu-specific. Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Augeas Integration
On Fri, Apr 1, 2011 at 4:00 PM, Etienne Goyer wrote: > We discussed Augeas at a previous UDS (circa 2009, not sure when). It's > an interesting concept, and I think there is some value in it. > > Back then, the main problem was that Augeas identified configuration > files by path, and these where hard-coded for Red Hat. It's really not > a big deal, I guess that can be fixed, but is it still the case? > Quite a few Debian paths have been added (and even Debian specificities) to the standard Augeas lenses. Lenses must know about standard OS paths for configuration files, but it's not a big deal to add these paths (either in Ubuntu as patches, in Augeas directly - I'm a committer -, or upstream if they take up maintenance). In order to avoid patching/forking, it's also possible to make new lenses that use the lens and modify the file filter, saying something like: use the httpd.aug lens on /etc/apache2/apache2.conf (this is already the case by default in httpd.aug, it's just to provide an example). Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Byobu
On Fri, Apr 1, 2011 at 4:43 PM, Dustin Kirkland wrote: > On Fri, Apr 1, 2011 at 9:22 AM, Serge E. Hallyn > wrote: >> Quoting Dustin Kirkland (kirkl...@ubuntu.com): >>> 2011/4/1 Raphaël Pinson : >>> > Also, a few years back, I had begun to work on making screen ACLs >>> > easier in byobu, but had not found the time to finish that part. Since >>> > Ubuntu encourages the use of user accounts vs root, this is a feature >>> > that could be very useful on Ubuntu servers I think. >>> >>> That's a great idea, Raphael. Actually, I was talking with Dave >>> Walker about this recently. Basically, I'm just going to move the >>> screen configuration magic from screenbin into byobu, and I think >>> we'll have almost everything we need. >> >> Use of acls requires a setuid-root screen binary, though, right? That's >> a huge change. > > Correctly I identified, Serge! You have dug into the "almost" in the > "we'll have almost everything we need" statement above :-) > > So here's what I'm thinking ... > > 1) Byobu would ship a profile in /usr/share/byobu/profiles/sharing > that has the relevant configuration bits. Top of my head, that's > mostly this (where the guest user is called "guest"). I'll need to do > some work to make this configurable. > > aclumask guest+r guest-w guest-x > aclchg guest +r-w-x '#?' > aclchg guest +x 'prev,next,select,detach' > multiuser on > That's a good idea for basic needs. > 2) Byobu would add a dialog to the F9:Menu that allows you to choose > the user you want to share the screen with, and select read-only or > read-write. It would also run something like > '/usr/bin/byobu-verify-sharing' and check the exit code and stderr > text. I have a prototype (based on an old version of byobu) on [0], which allows to choose the users you want to add and which rights you want to grant. I gave up developing it a year ago because I was stuck with screen ACLs parsing. To be clear, screen lets you set ACLs, but not see the ACLs you set, so my code worked fine as long as you only used byobu for ACLs, but it was a big mess if you began using screen directly since byobu was unaware of the changes. > 3) /usr/bin/byobu-verify-sharing would check the permissions on > /usr/bin/screen. If the permissions are incorrect, it would print > some text to the screen that your system administrator would need to > run in order to use screen sharing. Again, top of my head it might > look something like this: > > $ byobu-verify-sharing > ERROR: byobu screen sharing is not enabled > INFO: (1-2 lines here about setuid binaries, and why screen is not > setuid by default) > INFO: To enable byobu screen sharing, a system administrator must run: > sudo dpkg-statoverride --add root utmp 6755 /usr/bin/screen > sudo chmod 755 /var/run/screen > $ echo $? > 1 My current code does this kind of check already. > > 4) We could also add a "low" debconf question to the screen (or > byobu) package that asks this question at dpkg-reconfigure time (do > you want to enable screen sharing, setuid bits, on /usr/bin/screen). > That was my thought too (adding a debconf question). That, or using policykit in byobu to let users run the dpkg-statoverride without interacting with debconf. Is that possible? Raphaël -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Oneiric-Topic] Augeas Integration
Hello, In a (more or less) related subject to the Puppet integration thread, I would like to raise the idea of integrating Augeas [0] deeper in Ubuntu. Augeas is a unified configuration API which allows to parse and modify configuration files using XPath expressions. It features a C API, bindings for many languages (Python, Ruby, Perl, Haskell, Java, PHP, etc.) and a command line utility called augtool. The Ruby bindings have been used to provide a native Augeas Puppet type since Puppet 0.24.7. Augeas works by using bidirectional pieces of code called lenses. A lens is a grammar file which allows to parse a configuration file format and turn it into a tree, and then take a modified tree and write it back to the configuration files. Lenses ensure that only proper trees are written back to files, i.e. the syntax of the file written by Augeas is ensured by the lens. Currently, 90+ lenses are provided by Augeas. On a rather standard Lucid machine I have at work, Augeas is able to parse 141 files and produces 8054 nodes: rpinson@rpinson:~$ augtool match /augeas/files//path | wc -l 141 rpinson@rpinson:~$ augtool print /files | wc -l 8054 On the long run, Augeas is not meant to provide all these lenses, but instead we would like lenses to be shipped with each project, as a standard parsing and writing facility for configuration files across Unix systems. This would allow for example to bind the lenses with the version of the program providing the configuration files, ensuring that the lens parses and writes the proper configuration stanzas for the given version. This journey of sending lenses upstream and making Augeas a standard has to begin somewhere, and I'm suggesting to make it begin in Ubuntu, by including the lenses in each package they are related to. For example, the mysql.aug lens would be provided by the mysql-common package, and the httpd.aug package would be provided by apache2.2-common, etc. I would be happy to train package maintainers willing to take that step so they can maintain the lenses and make them evolve with time, or even send them to their upstream if they can. I would like to go even a step further in Ubuntu (and Debian if possible). Debian Policy, which Ubuntu developers follow, states (section 10.7.4, "Sharing configuration files" [1]): ``One of the related packages (the "owning" package) will manage the configuration file with maintainer scripts as described in the previous section. The owning package should also provide a program that the other packages may use to modify the configuration file. The related packages must use the provided program to make any desired modifications to the configuration file. They should either depend on the core package to guarantee that the configuration modifier program is available or accept gracefully that they cannot modify the configuration file if it is not. (This is in addition to the fact that the configuration file may not even be present in the latter scenario.)'' There are few packages currently that provide a program to manage their configuration files, making it hard for other packages to tune system configuration. One of the workarounds that are implemented in quite a few packages is to allow 'foo.d' kind of directories (e.g. sudoers.d, xinetd.d, pam.d, etc.). This allows packages to drop their configuration file without affecting other files, but it doesn't allow them to modify generic parameters. Once packages are shipped with their own Augeas lens, I suggest that policy could be adapted to allow the use of Augeas lenses provided by the owning packages as an alternative to using a program. This would allow for much more freedom to safely manipulate configuration files in package maintainer scripts. What are your thoughts on the subject? Cheers, Raphaël [0] http://www.augeas.net [1] http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] Byobu
I'm all for it! Also, a few years back, I had begun to work on making screen ACLs easier in byobu, but had not found the time to finish that part. Since Ubuntu encourages the use of user accounts vs root, this is a feature that could be very useful on Ubuntu servers I think. Raphaël On Wed, Mar 30, 2011 at 7:54 PM, D'nalkrik Nit-sud wrote: > I'd like to raise the (biannual) proposition that we consider > launching Byobu by default on Ubuntu Server installs for at least part > of the Oneiric cycle. As an LTS-1 release, this provides an ideal > opportunity (Alpha1-3?) to innovate and differentiate, while still > allowing for recalibration and reconsideration ahead of the subsequent > stability-focused LTS cycle. > > Byobu has come a long way in the last 2.5 years, having addressed many > of the early concerns about functionality, stability, and usability. > New features, such as horizontal and vertical splitting, and > traditional ones such as convenient keybindings and dozens of > real-time monitors provide a rich, unique command line experience for > many Ubuntu users. Byobu has won the praise of numerous users, > bloggers, and magazines, with many people swearing by its utility. > > That praise is not unanimous, of course (though what is unanimous in > Ubuntu these days?). So such a change would be easily overridden by > the following preseed parameter (and could even be a single question > in the installer): > byobu byobu/launch-by-default boolean false > > At login, the user would be clearly informed that this is brand new > behavior which can be trivially and permanently reverted with the > command: > $ byobu-disable > > Furthermore, derivative distributions should be able to cleanly and > easily opt in or out of this change. > > At the very least, I suggest that we consider enabling Byobu by > default for our cloud images that necessarily run detached and > "elsewhere" -- which is really where Byobu shines! Byobu provides > some distinct advantages over numerous indistinguishable cloud images > on the market. Shall we take a risk and innovate a bit here? At > least for a couple of non-LTS Alpha releases? Or perhaps localized to > our cloud images? > > -- > D'nalkrik Nit-sud > Registered Byobu user #0001 > > Okay, okay ... it's really Dustin Kirkland, of course. > > -- > ubuntu-server mailing list > ubuntu-server@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam > -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Fwd: Call for talks for the Configuration Management DevRoom at fosdem 2011]
Hi all, Two years back, I gave a talk on Augeas at FOSDEM. Since Augeas is right in the subject and tightly integrated with Puppet, it might be a good idea to give a talk about it this year as well. Raphaël On Tue, Dec 21, 2010 at 8:08 PM, Clint Byrum wrote: > This seems like a good forum to talk about the work we're doing with > Puppet and Cobbler (and I'm aware that thus far, we haven't talked much > about the Cobbler work, but thats only because we've been moving really > fast). > > Any volunteers? > > Forwarded Message > > From: James Turnbull > > Reply-to: cobbler mailing list > > To: fos...@lists.fosdem.org > > Cc: cobb...@lists.fedorahosted.org > > Subject: Call for talks for the Configuration Management DevRoom at > > fosdem 2011 > > Date: Mon, 20 Dec 2010 13:45:18 -0800 > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > **Call for talks for the Configuration Management DevRoom at fosdem > 2011** > > > > FOSDEM 2011 - http://fosdem.org/2011/ > > > > 6 February 2011, 09:00 to 17:00, Brussels, Belgium > > > > Contact: fosdem2...@puppetlabs.com > > > > We will be holding a Configuration Management DevRoom at fosdem 2011 and > > are requesting abstracts for structured presentations now. > > > > Important information, dates: > > > > ? Submission deadline for abstracts: 2011-01-08 > > > > ? Notification of accepted speakers: 2011-01-10 > > > > ? Final schedule: 2011-01-11 > > > > **About this DevRoom** > > > > Configuration Management is exciting! It is. Really. There is huge > > interest in automation, configuration management and especially PAAS, > > SAAS, IAAS and the cloud generally. We're seeking people who are > > working the field, interested in the field, or just interested in > > learning more about how to make their lives easier with automation and > > configuration management. > > > > We invite you to submit talks on these topics: > > > > * Configuration Management theory principles > > * Configuration Management tools - real world use cases > > * Tools, techniques and case studies > > * Configuration Management and the Cloud > > * Configuration Management, Compliance and Security > > > > NOTE: Puppet Labs is helping organise this room but we're looking for > > talks on more than Puppet! We're looking for CFengine, Chef, bcfg2, > > AutomateIT, and the myriad of other tools out there. > > > > ** Your submission must include:** > > > > * Your name > > > > * The title of your talk > > > > * A short abstract of one to two paragraphs (150 words, max.) > > > > * A short biography > > > > * Links to related websites/blogs etc. > > > > Send the abstracts to: > > > > fosdem2...@puppetlabs.com > > > > Presentations are to be formal and not longer than 30 minutes, plus 15 > > extra for questions (45 in total). Panels with more than one speaker are > > something we're also seeking, a "My configuration management tools is > > the awesomest and I'll debate that!" is possible, as are shorter > > presentations of 20 minutes. We're also exploring some un-conference > > style presentations too. > > > > The deadline for submissions is January 8th 2011. If your > > proposal has been accepted, you will be informed by email by January > > 10th 2011. > > > > Please feel free to forward this call for abstracts and papers to > > relevant lists, people and sites. We're looking forward to seeing lots > > of interested folks, have lots of spirited presentations, debates, > > discussion and ... quite possibly drinking. > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.7 (Darwin) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iQEVAwUBTQ/ObiFa/lDkFHAyAQL/JAf9EJQexmBYS8VGcRiCwmOkOyaiCMTNC7DA > > +khVdgCBNZgz5fz7lrXIw+oEYfj8MuIMW0jd2Fxpdc628y6hSG8PC1Y5/umKyYQI > > JYxN9AYYu81rd1Gn7W54qN3ihNibqvJQWpi2jT00uLY/DqFnb6WGWbK00bmLh2lY > > VnrtDRx8IoPKIVc0qoPfnKwmg2cw4RWQHqOrz8XwpPLyA2kjhvLmZV1MkYVu/h58 > > /Cxbai4IiqhurgHoYVb+AUvvenY/45oAXfKWx8+ZsKppTO/YhRu/SIpG3GQSmKGT > > uMdgmuQHFwvcdUWDMiR6ylGt14PIhmy4pXpAMVv4DtaRx48C7vwsPA== > > =oM7D > > -END PGP SIGNATURE- > > ___ > > cobbler mailing list > > cobb...@lists.fedorahosted.org > > https://fedorahosted.org/mailman/listinfo/cobbler > > > > -- > ubuntu-server mailing list > ubuntu-server@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam > -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
