Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: So where's that put kickstart? Or is the assumption that anyone who wants a more-minimal target won't be going that route? Many of the outside-of-anaconda tools use kickstart too; they just don't necessarily have the same rules for pulling in core automatically. I don't know if that's necessarily a great situation, since it means the same kickstart will do different things in different situations. Well, anaconda could change such that the interactive person explicitly specifies @core in kickstart, and we could then change anaconda's default to not always include it. Would require very large release notes, though. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 19, 2012 at 11:29:51AM -0500, Bill Nottingham wrote: Many of the outside-of-anaconda tools use kickstart too; they just don't necessarily have the same rules for pulling in core automatically. I don't know if that's necessarily a great situation, since it means the same kickstart will do different things in different situations. Well, anaconda could change such that the interactive person explicitly specifies @core in kickstart, and we could then change anaconda's default to not always include it. Would require very large release notes, though. I'm in favor, and now seems like the time to do it, as we're changing @base anyway. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/16/2012 06:35 PM, Matthew Miller wrote: On Fri, Nov 16, 2012 at 09:06:03PM -0500, Scott Schmit wrote: On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote: Tools outside of anaconda don't have to force @core, which opens those tools up to far more creative payloads. So where's that put kickstart? Or is the assumption that anyone who wants a more-minimal target won't be going that route? Many of the outside-of-anaconda tools use kickstart too; they just don't necessarily have the same rules for pulling in core automatically. I don't know if that's necessarily a great situation, since it means the same kickstart will do different things in different situations. This is kinda the point of breaking out pykickstart, so that other tools can make use of the kickstart file format and parsing utilities without having to drag in the rest of anaconda and anaconda's rules. In fact, pykickstart is all about the format and parsing. It's up to other tools to actually /act/ upon the data. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, Nov 15, 2012 at 4:32 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 15, 2012 at 01:13:09AM +0100, Lennart Poettering wrote: Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. That would be weird. But fortunately, it's @core, not @minimal. So we could easily have @minimal, @core, and @standard, each with different targets. Hm, the scope expansion happened rather quickly. Can we, for now, restrict ourselves to things that an ordinary sysadmin would encounter? That would, right now, mean anaconda-based or image-based installations of full systems. Anyone running custom scripts to create container chroots, or building hypervisor images where post-install files are removed from the system, is more of a programmer and therefore less reliant on us choosing a good default for the @core/@standard comps groups. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Fri, Nov 16, 2012 at 02:43:24PM +0100, Miloslav Trmač wrote: That would be weird. But fortunately, it's @core, not @minimal. So we could easily have @minimal, @core, and @standard, each with different targets. Hm, the scope expansion happened rather quickly. Can we, for now, restrict ourselves to things that an ordinary sysadmin would encounter? That would, right now, mean anaconda-based or image-based installations of full systems. +1. Specifically, regardless of the above distinction, we should really focus on @core. Anyone running custom scripts to create container chroots, or building hypervisor images where post-install files are removed from the system, is more of a programmer and therefore less reliant on us choosing a good default for the @core/@standard comps groups. I don't think more of a programmer is necessarily the right categorization, but I think not in need of specific comps group defaults is probably true. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote: hypervisor images where post-install files are removed from the system, is more of a programmer and therefore less reliant on us choosing a good default for the @core/@standard comps groups. I don't think more of a programmer is necessarily the right categorization, but I think not in need of specific comps group defaults is probably true. Tools outside of anaconda don't have to force @core, which opens those tools up to far more creative payloads. That was agreement, right? :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote: Tools outside of anaconda don't have to force @core, which opens those tools up to far more creative payloads. So where's that put kickstart? Or is the assumption that anyone who wants a more-minimal target won't be going that route? -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Fri, Nov 16, 2012 at 09:06:03PM -0500, Scott Schmit wrote: On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote: Tools outside of anaconda don't have to force @core, which opens those tools up to far more creative payloads. So where's that put kickstart? Or is the assumption that anyone who wants a more-minimal target won't be going that route? Many of the outside-of-anaconda tools use kickstart too; they just don't necessarily have the same rules for pulling in core automatically. I don't know if that's necessarily a great situation, since it means the same kickstart will do different things in different situations. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
From: Lennart Poettering mzerq...@0pointer.de I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) I don't believe embedded is out of focus for Fedora, I already have several hundred such systems, soon likely to scale into the thousands. It works quite well for this and I don't see any reason @core can't work to their benefit as well. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
From: Stephen John Smoogen smo...@gmail.com On 14 November 2012 17:19, Lennart Poettering mzerq...@0pointer.de wrote: Oh, I wasn't aware that this is solely about anaconda-based installs, sorry. Well actually I think the correct question here is.. is this about anaconda based installs which was my guess when reading through this. However it is an assumption.. which means I am probably as much an ass as an umption in it. How about images created with things such as livecd-tools? I don't know to what extent, if any, that anaconda is involved in those builds. Last time I checked, it did not appear to be so maybe this whole @core thing really is irrelevant to me. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 10:03:36PM -0800, Adam Williamson wrote: Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) That's basically what Kevin proposed several mails back, and I agree it seems like we have two broadly definable cases here rather than one. I think Bill Nottingham mentioned something similar too, although I don't want to put words into his mouth. I'm open to the possibility, but I think using default instead of mandatory for many packages in @core covers this distinction relatively well. Then we have @standard for the next level. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, Nov 15, 2012 at 01:19:59AM +0100, Lennart Poettering wrote: For containers a yum group for usage with --installroot= is the only thing that matters. For this, is a group even necessary or useful? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, Nov 15, 2012 at 01:13:09AM +0100, Lennart Poettering wrote: Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. That would be weird. But fortunately, it's @core, not @minimal. So we could easily have @minimal, @core, and @standard, each with different targets. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 11:28 AM, Matthew Miller wrote: I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's I was just working on a VMWare ESXI hypervisor which basically is a minimal Linux install, including a kernel running their virtualization hosting environment, and a busybox session. I found that there is a shockingly large amount of functionality in that busybox: we needed some network diagnostic tools, and discovered that it includes nc/netcat and ssh, as well as the usual ping/traceroute/nslookup/etc. I don't know if that is what you're after, because busybox duplicates the functionality of individual packages (and may have some limitations in how well it duplicates, I'm sure). All the same, I would definitely consider including it---it's of course available as a Fedora package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, Nov 15, 2012 at 10:59:26AM -0500, Przemek Klosowski wrote: I don't know if that is what you're after, because busybox duplicates the functionality of individual packages (and may have some limitations in how well it duplicates, I'm sure). All the same, I would definitely consider including it---it's of course available as a Fedora package. Well, this is part of what I mean by Fedora is not a tiny-linux distribution. It might be interesting to have a busybox-based spin, but I think that's a different thing. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/15/2012 11:18 AM, Matthew Miller wrote: On Thu, Nov 15, 2012 at 10:59:26AM -0500, Przemek Klosowski wrote: I don't know if that is what you're after, because busybox duplicates the functionality of individual packages (and may have some limitations in how well it duplicates, I'm sure). All the same, I would definitely consider including it---it's of course available as a Fedora package. Well, this is part of what I mean by Fedora is not a tiny-linux distribution. It might be interesting to have a busybox-based spin, but I think that's a different thing. Since busybox package already exists, I think it makes sense to use it--not because we're doing some tiny-linux, but because why not, it's just 651 kB. Most packages we discussed here (openssh-clients, sendmail) are individually much larger than that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: Since busybox package already exists, I think it makes sense to use it--not because we're doing some tiny-linux, but because why not, it's just 651 kB. Most packages we discussed here (openssh-clients, sendmail) are individually much larger than that. That's not a good reason to use busybox in a general install. It doesn't exactly duplicate the commands it offers, only a subset. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, Nov 15, 2012 at 11:31:52AM -0500, Przemek Klosowski wrote: Well, this is part of what I mean by Fedora is not a tiny-linux distribution. It might be interesting to have a busybox-based spin, but I think that's a different thing. Since busybox package already exists, I think it makes sense to use it--not because we're doing some tiny-linux, but because why not, it's just 651 kB. Most packages we discussed here (openssh-clients, sendmail) are individually much larger than that. We could just add the busybox binary, but doing that alone doesn't really get much. In order to be useful, you want links to the commands you want busybox to implement. And then, I suppose we'd want some way for those commands to automatically get out of the way when full-featured versions are installed (I guess install in an alternate dir with less priority in $PATH than /usr/bin/). But since not every command is a literal drop-in replacement for the full-featured Fedora versions, that could be confusing (and for scripts, buggy). -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Wed, Nov 14, 2012 at 10:03:36PM -0800, Adam Williamson wrote: Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) That's basically what Kevin proposed several mails back, and I agree it seems like we have two broadly definable cases here rather than one. I think Bill Nottingham mentioned something similar too, although I don't want to put words into his mouth. What I had suggested at one point was we have an 'image-base' group that is *really* tiny, that is intended to be used as a basis for creating images, chroot, and other things where you're not necessarily doing package management *on the running system*. So it would be: kernel systemd initscripts util-linux bash and their dependencies. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. That would be weird. But fortunately, it's @core, not @minimal. So we could easily have @minimal, @core, and @standard, each with different targets. @core is what's shown as the minimal install in anacona. We could do some renaming, but having @minimal, and having it *not* be the minimal install in anaconda, sounds like a really bad idea. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, Nov 15, 2012 at 10:12 PM, Bill Nottingham nott...@redhat.com wrote: Matthew Miller (mat...@fedoraproject.org) said: Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. That would be weird. But fortunately, it's @core, not @minimal. So we could easily have @minimal, @core, and @standard, each with different targets. @core is what's shown as the minimal install in anacona. We could do some renaming, but having @minimal, and having it *not* be the minimal install in anaconda, sounds like a really bad idea. We could have @core, @container and @cloud ... trying to fit multiple cases in one group just wont work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/13 Bill Nottingham nott...@redhat.com [...] - Minimal tools for admins less man-db procps-ng vim-minimal Is man-db really necessary? In the man pages included in the man-db package are not really helpful for a core system ... from my point of view. [...] - Get mail off the box (and define a default for doing so) sendmail Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the old days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 12:37:38AM -0500, Seth Vidal wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. I would say this is not accurate. My experience with the instances running under xen is that that is true. My experience with the instances running in euca under kvm is that that is not true. I didn't mean to imply that it's true everywhere. It's just true enough places that we shouldn't make it mandatory. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 01:27:21PM +0100, Thomas Bendler wrote: - Minimal tools for admins less man-db procps-ng vim-minimal Is man-db really necessary? In the man pages included in the man-db package are not really helpful for a core system ... from my point of view. I'd like to go back a step here to the question starting the thread. There's plenty of time to go over each package, but the basic question is intent. Clearly man pages aren't necessary for a super-minimal JEOS image, but that's not *historically* been the intent of @core, and based on the discussion so far I think it will continue to not be. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Thomas Bendler m...@bendler-net.de said: Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the old days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Matthew Miller mat...@fedoraproject.org [...] I'd like to go back a step here to the question starting the thread. There's plenty of time to go over each package, but the basic question is intent. Clearly man pages aren't necessary for a super-minimal JEOS image, but that's not *historically* been the intent of @core, and based on the discussion so far I think it will continue to not be. [...] Ok, but what is the intent? The first mail was a questioning what should be the scope of core and I didn't see a discussion answering this question. I think we should first define the mission statement and then discuss the technical details. Or is it only unclear to me what the intent is? Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 03:24:04PM +0100, Thomas Bendler wrote: Ok, but what is the intent? The first mail was a questioning what should be the scope of core and I didn't see a discussion answering this question. I That's *this* discussion. :) think we should first define the mission statement and then discuss the technical details. Or is it only unclear to me what the intent is? I kind of skipped past the mission statement because no one commented on the draft one I made, which is: The Fedora Minimal Core SIG ensures that the Fedora minimal package set is an intentionally curated selection rather than an ad hoc accretion of packages. to the first of the stated goals, which is: Choose a working definition for minimal (kernel + systemd only vs enough to get to yum install over the net vs basic traditional unix system). Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Matthew Miller mat...@fedoraproject.org default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools I was just surprised that there was no discussion about your proposal, instead, there was immediately a discussion about the packages that should be in core. So should this definition be the one that we are working on? From my point of view, core should only contain kernel, network, ssh-server plus yum to be ready for installation (locally and remotely). But if the rest of the group say, no, we need more (i.e. minimal admin tools), fine with me. But then we have something that we agreed on and that can be documented as the core base. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Thomas Bendler m...@bendler-net.de said: True, but then you need a mail client as well otherwise you won't see the local mails. So the question is, what is the definition of core? What should be the goal of core? Ehh, for local root mails from failing cron jobs, less /var/mail/root works just fine. :) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
From: Stephen John Smoogen smo...@gmail.com On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. bikeshed=blue They say it is but it is not always. I have had multiple cases in KVM and some in Xen where supposedly the clock is kept up but what you end up is actually watching time go backwards if you hit heavy load in IO or CPU or Mem. Of course if you run into hardware like that.. you can install it after your DB has gone poopsies. /bikeshed I've seen that happen as well. I found this by hitting the pause button on the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP (whether ntpd or chronyd) belongs in @standard not @core. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
From: Chris Adams cmad...@hiwaay.net Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. From my experience, an MTA is still not required. Any stdout/err from the cron jobs just go to the syslog, but this may be systemd's journal magic that I've been seeing. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Chris Adams cmad...@hiwaay.net [...] Ehh, for local root mails from failing cron jobs, less /var/mail/root works just fine. :) Sending mails with telnet also works fine but I don't think that this is the question ;). We work on the definition of core and what will be inside. If we say, mail must be inside we should also install a client to access the mail. That's why I wrote, we should define what core is first (and document it) and then talk about the packages which should be in core. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:55:50 PM Adam Williamson wrote: So far everything works without, and I think we should endevor to keep that true. I think this is similar to the firewalld issue in that the basic theory here is that, look, NetworkManager is the way, the truth and the light: it's supposed to be the One True Networking System, and we're just keeping the network service around because there's some stuff it does that NM doesn't do yet. This logic is getting a tad stretched because we've been rolling with it for several years at this point, but AIUI this is still the party line and the reason NetworkManager is in core. In theory the idea is not that we provide, actively maintain and support both NM and the network service, but that we want to only provide, maintain and support NM, and we're keeping the legacy 'network service' stuff around only until NM is done. It might be worth re-evaluating whether that's realistic any more, though, and whether we're really committed to finally replacing network with NM in some kind of reasonable timeframe. For Common Criteria purposes, everything running as root goes under the microscope and its painful and costly. We have to avoid that. If NM did not run as root and just retained whatever capability it needed, then we have an easier time. Same thing with firewalld. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12.11.12 11:28, Matthew Miller (mat...@fedoraproject.org) wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. What do you think? I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, 15.11.12 00:56, Lennart Poettering (mzerq...@0pointer.de) wrote: I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: ...snip... I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. That doesn't look like an intersection to me. ;) How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 08:18, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Thomas Bendler m...@bendler-net.de said: Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the old days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. I am pretty sure the default should be to push everything to the logs. But note that in the container case you are likely to encounter a setup where you install the host host, and then add one container for mail, another one for web, a third one for database, and so on. If you do that it would be really bogus to include sendmail in the minimal set... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 10:34, john.flor...@dart.biz (john.flor...@dart.biz) wrote: From: Chris Adams cmad...@hiwaay.net Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. From my experience, an MTA is still not required. Any stdout/err from the cron jobs just go to the syslog, but this may be systemd's journal magic that I've been seeing. cronie is actually able to log the cron output to syslog since a long time. I haven't been running MTAs on any of my machines for a many years now. If you deinstall the MTA then cronie will log a error message that sendmail wasn't around, and then go on and log job output to syslog. This error message is really pointless and should go away. Honestly, we really should drop sendmail from the default install of *all* systems, not just the minimal installations. It is simply not useful without configuration, and nothing else we install requires it, not even cronie. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 17:05, Kevin Fenzi (ke...@scrye.com) wrote: On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: ...snip... I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. That doesn't look like an intersection to me. ;) Well, if you look at all the usecases it happens that the container usecase ends up being the most minimal, and hence the intersection of all of them. How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 14 November 2012 17:13, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 14.11.12 17:05, Kevin Fenzi (ke...@scrye.com) wrote: On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: ...snip... I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. That doesn't look like an intersection to me. ;) Well, if you look at all the usecases it happens that the container usecase ends up being the most minimal, and hence the intersection of all of them. How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 17:15, Stephen John Smoogen (smo...@gmail.com) wrote: How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). Oh, I wasn't aware that this is solely about anaconda-based installs, sorry. For containers a yum group for usage with --installroot= is the only thing that matters. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 14 November 2012 17:19, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 14.11.12 17:15, Stephen John Smoogen (smo...@gmail.com) wrote: How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). Oh, I wasn't aware that this is solely about anaconda-based installs, sorry. Well actually I think the correct question here is.. is this about anaconda based installs which was my guess when reading through this. However it is an assumption.. which means I am probably as much an ass as an umption in it. For containers a yum group for usage with --installroot= is the only thing that matters. Where I think the core-container would go to define that. But again.. my assumptions may be as wrong as anything. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Time synchronization inside virtual machines is a. Hypervisor-dependent. See the docs for VirtualBox, VMware, Xen and kvm and read the fine print. I don't even know if there *is* documentation for EC2. b. Poorly documented and difficult to test. If you don't *need* anything better than NTP / one second synchronization, don't waste your time. c. A mine field if you *do* need something better. Stay safe out there. ;-) On Wed, Nov 14, 2012 at 7:22 AM, john.flor...@dart.biz wrote: From: Stephen John Smoogen smo...@gmail.com On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. bikeshed=blue They say it is but it is not always. I have had multiple cases in KVM and some in Xen where supposedly the clock is kept up but what you end up is actually watching time go backwards if you hit heavy load in IO or CPU or Mem. Of course if you run into hardware like that.. you can install it after your DB has gone poopsies. /bikeshed I've seen that happen as well. I found this by hitting the pause button on the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP (whether ntpd or chronyd) belongs in @standard not @core. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 4:03 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 15.11.12 00:56, Lennart Poettering (mzerq...@0pointer.de) wrote: I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It's been a while since I did anything with containers (LXC) but as I recall they're pretty much unmanageable without being able to ssh into them. But yes, I do think the bare-assed minimum viable Fedora is an LXC guest that one can get a console of some kind on and install packages into via yum. I'd even be willing to give up vim for nano. I don't need bash-completion or locate or man pages. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) SCOPE CREEP ALARM! AWOOGA! AWOOGA! Unless you actually think the network scripts are a better way of managing casual wireless connections, I think this is a bit out of scope, as we can already chalk up 'casual wireless connections' in the 'win' column for NetworkManager - it's already better than network.service at that. it may not be *perfect*, but it's *better*. The context here is not 'let's all get our NM pet peeves out of our systems', but 'what does network.service still do better than NM, and how long is it going to take to fix that?' -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 15.11.2012 02:19, Lennart Poettering wrote: For containers a yum group for usage with --installroot= is the only thing that matters. FWIW, For me Anaconda is overkill for the KVM guest images too. I am used to do that with small xquery script (easy for the libvirt domain definition) containing: yum (conf, root) install setup kernel acpid chrony acl attr audit rsyslog dhclient openssh-server openssh-clients rootfiles yum (yum dep-solves the above to 152 packages for F17, x86_64) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) SCOPE CREEP ALARM! AWOOGA! AWOOGA! Unless you actually think the network scripts are a better way of managing casual wireless connections, I think this is a bit out of scope, as we can already chalk up 'casual wireless connections' in the 'win' column for NetworkManager - it's already better than network.service at that. it may not be *perfect*, but it's *better*. The context here is not 'let's all get our NM pet peeves out of our systems', but 'what does network.service still do better than NM, and how long is it going to take to fix that?' -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel In the current context, a minimal Fedora, I'd argue that NetworkManager is overkill too. An openSUSE / SUSE Studio JEOS or server appliance defaults to some kind of DHCP client built on top of whatever the base networking tools are in openSUSE. You have to specifically *ask* for NetworkManager if you want it. I don't even think the bridge tools are included at that minimalist level. You get a firewall, yes, and DHCP too but ssh is optional - you probably have to go in with 'vi' from the console and edit configuration files to make networking happen beyond that. While we're on the subject of minimalism, does yum default to installing suggested packages on top of required ones? -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote: Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) Alternatively, I could see where the first is marked required, but the second is marked default so it can be deselected in a kickstart config without needing to rpm -e it in %post. -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 18:49 -0800, M. Edward (Ed) Borasky wrote: On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. In the current context, a minimal Fedora, I'd argue that NetworkManager is overkill too. We're going round in circles, here. The post of mine quoted above - five levels of quotation deep, 11/13/2012 - was a reply to someone saying the same thing. Please just read back to there, and break us out of this eternal loop. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 22:23 -0500, Scott Schmit wrote: On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote: Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) That's basically what Kevin proposed several mails back, and I agree it seems like we have two broadly definable cases here rather than one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/12 Matthew Miller mat...@fedoraproject.org [...] Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? Depends on the scope. I think that the B definition plus ssh-server goes into the right direction. The minimal system should have networking in place and ssh ready to interact with the fresh installation. More stuff is not necessary. If you need more, invoke yum and install whatever you need (so yum should also be in the core definition). Things like cron, MTA and other stuff should from my point of view not be in the core installation, this is more something like core plus lsb. Regards Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/13 Christopher Meng cicku...@gmail.com I don't know Fedora minimal looks like...FOR SERVER USE the Minimal includes: [...] BUT FOR DESKTOP USE,I think it should also have a desktop based on server version...That's what is troubling me...If it [...] This is something we shouldn't mix. When we are talking about core I would assume it is the core for everything, regardless if it is a server or a desktop. So if we talk about server minimal or desktop minimal, we talk about core + X for server minimal and core + Y for desktop minimal. So from my point of view, core is not minimal, it is the base for every later taste, regardless if server, desktop, mobile or whatever. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
A minimal subset of python (was Re: [@core] working definition for the minimal package set)
On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. If we're targeting yum as core functionality, that implies a subset of Python: enough to run yum at least, but probably not much more. This ties into https://bugzilla.redhat.com/show_bug.cgi?id=867962 which I'd prefer to solve by introducing a python-core package. I've heard complaints from upstream that no-one can know what the python package means on any given distribution (everyone splits it out in slightly different ways). Fixing that suggests that the python package should become a metapackage that brings in everything built from the python tarball. If we go down this route, say in Fedora 19, then let's introduce a python-core or somesuch, and define it loosely to be whatever yum needs in the minimal environment. Does this sound sane? (especially from the POV of yum developers) What does yum need? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A minimal subset of python (was Re: [@core] working definition for the minimal package set)
Did a quick scan and removed internals random : ['import random : (cli.py)'] subprocess : ['from subprocess import Popen, PIPE : (yum/packages.py)'] gettext : ['import gettext : (output.py)'] fnmatch : ['import fnmatch : (completion-helper.py)'] tempfile : ['import tempfile : (yum/misc.py)'] base64 : ['import base64 : (yum/misc.py)'] imp : ['import imp : (yum/plugins.py)'] logging.config : ['import logging.config : (yum/__init__.py)'] string : ['import string : (yum/__init__.py)'] textwrap : ['from textwrap import fill : (yum/plugins.py)'] urlgrabber.grabber : ['from urlgrabber.grabber import URLGrabError : (output.py)'] iniparse.compat : ['from iniparse.compat import NoSectionError, NoOptionError, ParsingError : (yum/config.py)'] ConfigParser : ['from ConfigParser import ConfigParser, ParsingError : (yum-updatesd.py)'] cmd : ['import cmd : (shell.py)'] uuid : ['from uuid import uuid4 : (yum/misc.py)'] logging.handlers : ['import logging.handlers : (yum/logginglevels.py)'] threading: ['import threading : (yum-updatesd.py)'] shlex: ['import shlex : (completion-helper.py)'] signal : ['import signal : (cli.py)'] cStringIO: ['from cStringIO import StringIO : (yum/mdparser.py)'] locale : ['import locale : (output.py)'] xml.sax.saxutils : ['import xml.sax.saxutils : (yum/misc.py)'] lzma : ['import lzma : (yum/misc.py)'] sha : ['import sha : (yum/misc.py)'] urllib : ['import urllib : (yum/misc.py)'] re : ['import re # For YumTerm : (output.py)'] gpgme: ['import gpgme : (yum/misc.py)'] fcntl: ['import fcntl : (yum/rpmtrans.py)'] optparse : ['from optparse import OptionParser : (yum-updatesd.py)'] xml.etree: ['from xml.etree import cElementTree : (yum/mdparser.py)'] struct : ['import struct : (yum/packages.py)'] logging : ['import logging : (output.py)'] socket : ['import socket : (yum/logginglevels.py)'] weakref : ['from weakref import proxy as weakref : (output.py)'] sqlitecachec : ['import sqlitecachec : (yum/yumRepo.py)'] os : ['import os : (yum-updatesd.py)'] pdb : ['import pdb : (yummain.py)'] struct, time, cStringIO, base64, types curses : ['import curses : (output.py)'] __builtin__ : ['import __builtin__ : (shell.py)'] operator : ['import operator : (yumcommands.py)'] rpm : ['import rpm : (output.py)'] errno: ['import errno : (yummain.py)'] binascii : ['import binascii : (yum/misc.py)'] types: ['import types : (output.py)'] md5 : ['import md5 : (yum/misc.py)'] pwd : ['import pwd : (output.py)'] gpgme.editutil : ['import gpgme.editutil : (yum/misc.py)'] copy : ['import copy : (yum/config.py)'] hashlib : ['import hashlib : (yum/misc.py)'] atexit : ['import atexit : (yum/plugins.py)'] StringIO : ['import StringIO : (yum/__init__.py)'] exceptions : ['import exceptions : (utils.py)'] sqlutils : ['from sqlutils import sqlite, executeSQL, sql_esc : (yum/pkgtag_db.py)'] urlgrabber : ['import urlgrabber : (yum/__init__.py)'] sqlite : ['import sqlite : (yum/sqlutils.py)'] urlgrabber.progress : ['from urlgrabber.progress import TextMeter, TextMultiFileMeter : (output.py)'] shutil : ['import shutil : (yum/misc.py)'] xattr: ['import xattr : (yum/packages.py)'] bz2 : ['import bz2 : (yum/misc.py)'] grp : ['import grp : (yum/packages.py)'] sqlite3 : ['import sqlite3 as sqlite : (yum/sqlutils.py)'] stat : ['import stat : (yum/packages.py)'] warnings : ['import warnings : (yum/config.py)'] glob urlgrabber.mirror: ['import urlgrabber.mirror : (yum/yumRepo.py)'] iniparse : ['from iniparse import INIConfig : (yum/config.py)'] sys : ['import sys : (yum-updatesd.py)'] cElementTree : ['import cElementTree : (yum/mdparser.py)'] os.path : ['import os.path : (yummain.py)'] urlparse : ['import urlparse : (yum/config.py)'] Tim On Tue, Nov 13, 2012 at 5:09 PM, David Malcolm dmalc...@redhat.com wrote: On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. Well, I think it's just that the policy for a long time that since core isn't visible, default or optional are pointless. Specifically: http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#Core says (right now, but maybe not for long): Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools. That last part isn't even right. There's not too many packages in core, so I don't think it'll be that difficult of an excercise to find the reasoning for each. So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager - Connect to remote systems curl openssh-clients - Allow remote systems to connect to us openssh-server - Store forward logs audit rsyslog - Install other software rpm yum - SELinux policycoreutils selinux-policy-targeted - Add/remove/configure local users, and allow them to admin if necessary passwd shadow-utils sudo - Minimal tools for admins less man-db procps-ng vim-minimal - Scheduled tasks cronie - Get mail off the box (and define a default for doing so) sendmail - Support a local console kbd ncurses - Configure additional partitions for the simple case e2fsprogs parted - Probably legacy and can be dropped from explicit listing iprutils ppc64-utils Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:41:12 PM Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. Well, I think it's just that the policy for a long time that since core isn't visible, default or optional are pointless. Specifically: http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr oups#Core says (right now, but maybe not for long): Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools. That last part isn't even right. There's not too many packages in core, so I don't think it'll be that difficult of an excercise to find the reasoning for each. So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager Shouldn't iptables be here too? - Connect to remote systems curl openssh-clients - Allow remote systems to connect to us openssh-server - Store forward logs audit rsyslog As soon as you have logs, you need to be able to rotate them. So, I'd add logrotate and cronie at this point. Failure to rotate logs can fill the /var partition and then bad things happen. Thanks, -Steve - Install other software rpm yum - SELinux policycoreutils selinux-policy-targeted - Add/remove/configure local users, and allow them to admin if necessary passwd shadow-utils sudo - Minimal tools for admins less man-db procps-ng vim-minimal - Scheduled tasks cronie - Get mail off the box (and define a default for doing so) sendmail - Support a local console kbd ncurses - Configure additional partitions for the simple case e2fsprogs parted - Probably legacy and can be dropped from explicit listing iprutils ppc64-utils Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Bill Nottingham nott...@redhat.com said: So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) Plus a bootloader, which may be implicit (and I guess isn't absolutely required for at least some virtualization setups). What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager Is NM really required for basic networking? If so, you probably don't need to specify some of the rest (such as dhclient) manually. NM brings a bunch of deps I believe. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Is NM really required for basic networking? If so, you probably don't need to specify some of the rest (such as dhclient) manually. NM brings a bunch of deps I believe. So far everything works without, and I think we should endevor to keep that true. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). Seems like a possible candidate to have default but not mandatory in core. Nothing pulls it in. - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. Automatically added by anaconda when the system has LVM. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). Seems like a possible candidate to have default but not mandatory in core. Nothing pulls it in. It's in standard, not core. - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. Automatically added by anaconda when the system has LVM. If we want to rely on anaconda to add the filesystem tools for whatever FS you install, we could drop e2fsprogs. But we'd still want parted. (And I think leaving e2fsprogs in the minimal install likely makes sense anyway.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 05:20:43PM -0500, Bill Nottingham wrote: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. I hear that, but if you're in a big environment and you want root's dotfiles to be different, maybe you should be able to deselect the package? Automatically added by anaconda when the system has LVM. If we want to rely on anaconda to add the filesystem tools for whatever FS you install, we could drop e2fsprogs. But we'd still want parted. (And I think leaving e2fsprogs in the minimal install likely makes sense anyway.) I think it needs to be there for fsck. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 13 November 2012 15:22, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Nov 13, 2012 at 05:20:43PM -0500, Bill Nottingham wrote: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. I hear that, but if you're in a big environment and you want root's dotfiles to be different, maybe you should be able to deselect the package? I think this seems to be a bike shed issue. If I want different stuff I am going to be overlaying other stuff myself but if I don't have some sort of defaults starting out.. I end up in various pain. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 03:40:26PM -0700, Stephen John Smoogen wrote: from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. I hear that, but if you're in a big environment and you want root's dotfiles to be different, maybe you should be able to deselect the package? I think this seems to be a bike shed issue. If I want different stuff I am going to be overlaying other stuff myself but if I don't have some sort of defaults starting out.. I end up in various pain. This package is _so_ tiny there's really no point in arguing about it either way. It's basically the size of a rounding error. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, 2012-11-13 at 17:15 -0500, Matthew Miller wrote: Is NM really required for basic networking? If so, you probably don't need to specify some of the rest (such as dhclient) manually. NM brings a bunch of deps I believe. So far everything works without, and I think we should endevor to keep that true. I think this is similar to the firewalld issue in that the basic theory here is that, look, NetworkManager is the way, the truth and the light: it's supposed to be the One True Networking System, and we're just keeping the network service around because there's some stuff it does that NM doesn't do yet. This logic is getting a tad stretched because we've been rolling with it for several years at this point, but AIUI this is still the party line and the reason NetworkManager is in core. In theory the idea is not that we provide, actively maintain and support both NM and the network service, but that we want to only provide, maintain and support NM, and we're keeping the legacy 'network service' stuff around only until NM is done. It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. (It's also a possibility of course that I'm misunderstanding and that we do intend to provide and support 'network' for the foreseeable future, in which case I'd agree it should be in @core and NM should be only in @standard). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham nott...@redhat.com wrote: [list of packages] ntpdate chrony -- Ben Cotton Fedora Docs Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham nott...@redhat.com wrote: [list of packages] ntpdate chrony On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 8:38 PM, Matthew Miller mat...@fedoraproject.org wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. (Neat, I learned something today!) Sure, but there are a lot of Fedora instances not running on such environments. We could come up with plenty of use cases to exclude packages already mentioned in this thread, but that doesn't mean they shouldn't be included. -- Ben Cotton Fedora Docs Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 08:55:46PM -0500, Ben Cotton wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. (Neat, I learned something today!) Sure, but there are a lot of Fedora instances not running on such environments. We could come up with plenty of use cases to exclude packages already mentioned in this thread, but that doesn't mean they shouldn't be included. Yep, but cloud/virt is a major use case for the minimal install, so we certainly shouldn't make them mandatory there. I think time sync should be in @standard, though, and it is. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 13 November 2012 18:38, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham nott...@redhat.com wrote: [list of packages] ntpdate chrony On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. bikeshed=blue They say it is but it is not always. I have had multiple cases in KVM and some in Xen where supposedly the clock is kept up but what you end up is actually watching time go backwards if you hit heavy load in IO or CPU or Mem. Of course if you run into hardware like that.. you can install it after your DB has gone poopsies. /bikeshed -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Adam Williamson awill...@redhat.com said: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. Until NM supports 802.1q, bridging, and tunnels, to name a few things which AFAIK it does not yet, it isn't a suitable replacement. If/when it gets to the point it can handle all the things the basic network service/scripts can do, then having it in @core could be revisited. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Ben Cotton bcot...@fedoraproject.org said: ntpdate chrony Daemons should only be added to @core if they are critical for basic system function; NTP is recommended for most setups, but certainly not critical. It would be nice to have ntpdate and/or rdate though, so that the system clock can be initialized from the network. Trying to set it accurately by hand can be annoying, and an accurate clock is required for some network authentication methods like Kerberos. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
I can tell you what openSUSE / SUSE Studio does. The smallest appliance you can build is JEOS (Just Enough Operating System). That has kernel, grub, openssh, bash, small vim and zypper, which is the openSUSE equivalent of yum. It does not have man pages; they're stripped out. Next up is something called 'server'. The main thing you get beyond JEOS is a bigger system administration tool called YaST, which has a curses interface for things like the firewall. I think the man pages show up in 'server'. Neither JEOS nor server have 'ntp' or 'sudo' - you have to add those. You also have to add command-line conveniences like command-not-found, findutils-locate and bash-completion. Next up is Minimal X. This is a stripped IceWM desktop that's actually quite nice if you want X Windows. Personally I don't think anything smaller than JEOS is useful and I don't think it's necessary. It's only about 174 MB as an ISO On Tue, Nov 13, 2012 at 8:01 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Ben Cotton bcot...@fedoraproject.org said: ntpdate chrony Daemons should only be added to @core if they are critical for basic system function; NTP is recommended for most setups, but certainly not critical. It would be nice to have ntpdate and/or rdate though, so that the system clock can be initialized from the network. Trying to set it accurately by hand can be annoying, and an accurate clock is required for some network authentication methods like Kerberos. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, 13 Nov 2012, Matthew Miller wrote: On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham nott...@redhat.com wrote: [list of packages] ntpdate chrony On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. I would say this is not accurate. My experience with the instances running under xen is that that is true. My experience with the instances running in euca under kvm is that that is not true. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. What do you think? I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ ditto w/rsync. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote: On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. i think you misunderstand. if I am attempting to connect to a server running sshd: I can run ssh servername and that works I can run sftp servername and THAT works I cannot run scp servername I have to have a local scp client installed on the server for scp to work as a service. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:10 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote: On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. i think you misunderstand. if I am attempting to connect to a server running sshd: I can run ssh servername and that works I can run sftp servername and THAT works I cannot run scp servername I have to have a local scp client installed on the server for scp to work as a service. scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. Petr -- Petr Lautrbach, Red Hat, Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Petr Lautrbach wrote: scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:44 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Petr Lautrbach wrote: scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. A thin client would probably not want to install openssh-server. Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 07:10:21PM +0100, Petr Lautrbach wrote: A thin client would probably not want to install openssh-server. Bringing us back around to the point of this thread. :) Thin client is one use case. Server base is another. JEOS cloud image is another. We don't necessarily have to define @core such that it means only the bare minimum (although I think that's on the table, at least). It's useful to consider packages which might fit a broad reading of the use cases within the scope of this SIG. For example, if SSH suddenly grew a dependency on (picking on something at random) Django, I think we'd want to talk about it. That's one of the reasons I think it's useful to have a broader target. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Petr Lautrbach wrote: which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. A thin client would probably not want to install openssh-server. fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 12:21:43PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? Historically the @core group did not have anything other than mandatory packages as there was no UI to deselect them (because core was not a visible group). Core is still not a visible group, but there appears to be a few default packages in there now, But there was a non-UI way. Does that no longer work? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Jesse Keating wrote: On 11/12/2012 12:17 PM, Matthew Miller wrote: On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? Historically the @core group did not have anything other than mandatory packages as there was no UI to deselect them (because core was not a visible group). Core is still not a visible group, but there appears to be a few default packages in there now, NetworkManager, ppc64-utils, and sendmail. I'm not sure of the backstory on this, but now you can - those packages (provided nothing else requires them). More of @core could be made this way, if that was desired for the kickstarters. sendmail is in there so we didn't need a special case to make sendmail 'win' for the options for MTA. ppc64-utils is b/c I do not think we had another way to get it in for the ppc boxes. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Seth Vidal skvi...@fedoraproject.org writes: fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. Is kickstart installs generally out of scope for minimal package set? The problem used to be that even with kickstart, you ended up with a too-large package set which you then had to rpm -e at the end. Awkward. This has gotten much better, of course. Personally I was hoping that the minimal project would end up making it possible, using kickstart, to install enough to get yum running. Ideally the size of that minimal install would be rather small. The users can always add more... If people want an actual functional system out of the box, it seems that they would be better off with one of the other installation choices. But anyway, if it is possible to prevent the installation of openssh-* in the kickstart file, that is ok with me. rpm -e afterwards, not so much. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Benny Amorsen wrote: Seth Vidal skvi...@fedoraproject.org writes: fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. Is kickstart installs generally out of scope for minimal package set? The problem used to be that even with kickstart, you ended up with a too-large package set which you then had to rpm -e at the end. Awkward. This has gotten much better, of course. Personally I was hoping that the minimal project would end up making it possible, using kickstart, to install enough to get yum running. Ideally the size of that minimal install would be rather small. The users can always add more... If people want an actual functional system out of the box, it seems that they would be better off with one of the other installation choices. But anyway, if it is possible to prevent the installation of openssh-* in the kickstart file, that is ok with me. rpm -e afterwards, not so much. why is rpm -e in %post in the kickstart not okay? the system isn't 'up'. what harm is it in cleaning up crap? If you're doing enough installs that the bandwidth is an issue in installing these additional packages then you should make a local mirror, I'd think. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 01:42:02PM -0500, Matthew Miller wrote: On Mon, Nov 12, 2012 at 07:10:21PM +0100, Petr Lautrbach wrote: A thin client would probably not want to install openssh-server. Bringing us back around to the point of this thread. :) Thin client is one use case. Server base is another. JEOS cloud image is another. oVirt Node is another ... It's not really like any of the things discussed before: (a) It's sealed. You can't use yum to install packages, by design. (b) It's minimized. In order to fit it on very tiny flash disks, large parts such as docs and locales are 'rm -rf'd. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote: But there was a non-UI way. Does that no longer work? The non-UI way was kickstart. But you can't deselect (-) mandatory packages in a group. @core is primarily made up of mandatory packages. Huh. I could swear I've done that before and it worked. In any case, it is _certainly_ working with appliance-creator right now. :) This actually opens up another axis, here, so we could have one standard for mandatory packages (kernel+init, or up-to-yum+net) and a second level for default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the distinction between mandatory and deselectable is huge for kickstart, which I think is common for _most_ of our use cases. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
I think a minimal image is just like centos minimal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 10:13:54AM +0800, Christopher Meng wrote: I think a minimal image is just like centos minimal. Care to share what that means? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
I don't know Fedora minimal looks like...FOR SERVER USE the Minimal includes: Network support; BASH; Maybe some development tools also. Nothing else. BUT FOR DESKTOP USE,I think it should also have a desktop based on server version...That's what is troubling me...If it has a built-in desktop,I don't know if we can still treat it as minimal.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 05:25 PM, Matthew Miller wrote: On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote: But there was a non-UI way. Does that no longer work? The non-UI way was kickstart. But you can't deselect (-) mandatory packages in a group. @core is primarily made up of mandatory packages. Huh. I could swear I've done that before and it worked. In any case, it is _certainly_ working with appliance-creator right now. :) appliance-creator may not force @core. The force of @core is an anaconda thing. This actually opens up another axis, here, so we could have one standard for mandatory packages (kernel+init, or up-to-yum+net) and a second level for default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the distinction between mandatory and deselectable is huge for kickstart, which I think is common for _most_ of our use cases. Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. Well, I think it's just that the policy for a long time that since core isn't visible, default or optional are pointless. Specifically: http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#Core says (right now, but maybe not for long): Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools. That last part isn't even right. There's not too many packages in core, so I don't think it'll be that difficult of an excercise to find the reasoning for each. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
