Re: Fedora.next: I would like working configurations
Hi, THAT would be worhty of being called Fedora.Next . cu romal Am 28.01.14 01:35, schrieb Oron Peled: On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote: ... or some mechanism to interactively configure and deploy a DHCP server. IMO, that's exactly the crux of the matter. Most non-trivial services requires some administrative decisions to configure them properly. Since rpm does not allow interactive query of the user (IMO rightfully), everybody implement custom solutions: * Some custom scripts (e.g: freeipa-server-install) * Only hand configuration (e.g: dhcpd) * Some web-based PHP configuration (many php web-applications that look for an easy solution to a tough problem and forget about security along the way...) Just like packaging systems implemented a common framework to install software, we need a common framework to *configure* it (at least base configuration if the full configuration management problem is too tough). My suggestion is to look first at the debconf abstract model. Let's start with one design decision which I think we should avoid: * Debian triggers debconf operations from the package installer. This means package installation is potentially interactive (not good). I think the configuration mechanism should be explicitly called from elsewhere. (e.g: when administrator want to activate/configure the service). But now, let's look at the good properties which we can learn from: * All configuration options are name-spaced (in debconf it's done by package name) * Each configuration option has specific *type* info (string, boolean, multi-select, etc.) * A package installation register its configuration options in a system-wide database. * This also contains end-user visible text for each option including i18n. * The debconf database may be populated via different front-ends: GUI, TUI, command-line, web-based (experimental), preseed (for kickstart install). * All front ends need only understand the generic types of the options. (I.e: they provide generic configuration UI widgets which aren't modified when new packages/options are added) * The debconf API allows fetching any option from the database and the values of these options are used to configure the actual software. Note: I tried to abstract away the properties, because I don't think the debconf *implementation* fits what we need. However, the model shows how very different packages can use a common framework for basic configuration, just like RPM shows how very different packages can use a common framework for installation. Having such a framework would allow a *standard* way of configuring a set of packages for specific roles. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forwarding this to ser...@lists.fedoraproject.org as well. Responses inline. On 01/27/2014 07:35 PM, Oron Peled wrote: On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote: ... or some mechanism to interactively configure and deploy a DHCP server. IMO, that's exactly the crux of the matter. Most non-trivial services requires some administrative decisions to configure them properly. Since rpm does not allow interactive query of the user (IMO rightfully), everybody implement custom solutions: * Some custom scripts (e.g: freeipa-server-install) * Only hand configuration (e.g: dhcpd) * Some web-based PHP configuration (many php web-applications that look for an easy solution to a tough problem and forget about security along the way...) I realize you address this below somewhat, but I want to call out that what you're describing here is the *presentation layer* of configuration, not necessarily the configuration itself. In general, the vast majority of applications keep their configurations in 1) a set of text files, 2) a project-specific database or 3) a combination of the two) If projects provide a set of tools to manipulate this configuration, that's separate from the configuration itself. As we start talking about applying configuration to a system, we can reuse existing tools where they make sense, but it's also reasonable to say that we might choose to bypass them and use a tool such as Augeaus or Puppet to apply the configuration we want. Just like packaging systems implemented a common framework to install software, we need a common framework to *configure* it (at least base configuration if the full configuration management problem is too tough). My suggestion is to look first at the debconf abstract model. Let's start with one design decision which I think we should avoid: * Debian triggers debconf operations from the package installer. This means package installation is potentially interactive (not good). I think the configuration mechanism should be explicitly called from elsewhere. (e.g: when administrator want to activate/configure the service). Yes, I agree. Simple package installation must not require interaction. We should define that as a fundamental tenet of our approach. We need it to always be possible to have unattended or scripted operation. But now, let's look at the good properties which we can learn from: * All configuration options are name-spaced (in debconf it's done by package name) Yeah, obviously we'll need to maintain simple distinction about how we maintain the data. Namespacing is one option. Another might be to use an object-oriented API where we have objects associated with each service (not necessarily package...) that have configuration options specified as their attributes. * Each configuration option has specific *type* info (string, boolean, multi-select, etc.) Extending the above, one of my thoughts on another thread on the Fedora Server mailing list is to use D-BUS for the configuration API. Among other things, we have the D-BUS object types to work with. This would mean that we can have service-specific objects with appropriately-typed options. * A package installation register its configuration options in a system-wide database. I'm not sure this makes sense. This would require us to maintain data in two places, because zero existing packages would *retrieve* their data from this location. We'd have a duplication problem and we would also be responsible for bi-directional sync (if someone hand-edited a configuration file, we'd need to read it back into the database). I think it makes more sense to build an API around something like Augeaus and rely on being able to read and write the configuration that the packages already understand. * This also contains end-user visible text for each option including i18n. I think it would be better to handle this at the API layer, rather than in a database. * The debconf database may be populated via different front-ends: GUI, TUI, command-line, web-based (experimental), preseed (for kickstart install). Again, if we build a sensible API, it should be possible to build whatever presentation layer we want to atop it. Of note, we're planning to work with the Cockpit Project for our reference implementation. * All front ends need only understand the generic types of the options. (I.e: they provide generic configuration UI widgets which aren't modified when new packages/options are added) I don't agree with this. Providing just a text entry box and a description isn't an effective UI technique, particularly if you want to be able to produce guided or wizard-based operation. (For example, if you have branching decisions during configuration). * The debconf API allows fetching any option from the database and the values of these options are used to configure the actual software. See above for
Re: Fedora.next: I would like working configurations
On Tuesday 28 January 2014 08:23:46 Stephen Gallagher wrote: Forwarding this to ser...@lists.fedoraproject.org as well. Responses inline. As I'm not on the server list (yet), I replied to both lists. If devel should be off this thread, just remove it in your next reply and I'll understand the hint. I realize you address this below somewhat, but I want to call out that what you're describing here is the *presentation layer* of configuration, not necessarily the configuration itself. In general, the vast majority of applications keep their configurations in 1) a set of text files, 2) a project-specific database or 3) a combination of the two) If projects provide a set of tools to manipulate this configuration, that's separate from the configuration itself. As we start talking about applying configuration to a system, we can reuse existing tools where they make sense, but it's also reasonable to say that we might choose to bypass them and use a tool such as Augeaus or Puppet to apply the configuration we want. +1 My point was that creating a standard *model* does not prevent us from choosing different mechanisms for the implementation. It simply hides those differences behind a standard interface[s]. Just like packagers may use different contents in their %build section but *every* package is still being built with the same rpmbuild command. Yes, I agree. Simple package installation must not require interaction. We should define that as a fundamental tenet of our approach. We need it to always be possible to have unattended or scripted operation. +1 Yeah, obviously we'll need to maintain simple distinction about how we maintain the data. Namespacing is one option. Another might be to use an object-oriented API where we have objects associated with each service (not necessarily package...) that have configuration options specified as their attributes. OO API is fine, as long as all classes present a unified *interface*. About name-spacing/scoping: * If a package contain more than one service, the scoping may be more fine-grained/narrow than a package -- no problem. * However, if the highest level scope is a package -- than each package may simply contain its configuration definitions. [I'm talking about the configuration keys+types, not their values]. * Advantages of such a design: - When a package is installed, its configuration options are exposed (simply because its configuration definition files are there) - A package is still self-contained and fully describe its software (including the available configuration options). Extending the above, one of my thoughts on another thread on the Fedora Server mailing list is to use D-BUS for the configuration API. Among other things, we have the D-BUS object types to work with. This would mean that we can have service-specific objects with appropriately-typed options. Sounds like a great idea: * As you said we automatically gain all D-Bus goodies (including a fully developed type-system). * Also, I think we can map it to some data-driven syntax. Example: * For simplicity, let's assume each configuration item is a D-Bus property. * Than a package may install a configuration definition file: /usr/share/system-config-data/package/foo.conf-defs: D-Bus interface object property ro/rw/wo * So a generic configuration engine that read all these files, should have no trouble accessing these properties, presenting them to the user (according to their types) and then inject the user choice over D-Bus. * The packager would have to supply implementation for these objects, but we may ease this for most packages by supplying some common classes which can be easily inherited from. [obviously, this part is the toughest to get right] * A package installation register its configuration options in a system-wide database. I'm not sure this makes sense. This would require us to maintain data in two places, because zero existing packages would *retrieve* their data from this location. We'd have a duplication problem and we would also be responsible for bi-directional sync (if someone hand-edited a configuration file, we'd need to read it back into the database). I suspect my choice of words (database) wasn't so good. I didn't mean storing the configuration *values*, only the available configuration options. Perhaps calling it catalog would have made more sense. Basically, in debconf it contains a list of all possible configuration entries. Each with: * A fully qualified name (including the package it belongs to). * Type info. * Available translations. I think it makes more sense to build an API around something like Augeaus and rely on being able to read and write the configuration that the packages already understand. Sure. If we can wrap Augeaus in some base class, than the implementation of most packages would be: * Inherit from this base
Re: Fedora.next: I would like working configurations
On Wed, 2014-01-29 at 01:48 +0200, Oron Peled wrote: On Tuesday 28 January 2014 08:23:46 Stephen Gallagher wrote: Forwarding this to ser...@lists.fedoraproject.org as well. Responses inline. As I'm not on the server list (yet), I replied to both lists. If devel should be off this thread, just remove it in your next reply and I'll understand the hint. I realize you address this below somewhat, but I want to call out that what you're describing here is the *presentation layer* of configuration, not necessarily the configuration itself. In general, the vast majority of applications keep their configurations in 1) a set of text files, 2) a project-specific database or 3) a combination of the two) If projects provide a set of tools to manipulate this configuration, that's separate from the configuration itself. As we start talking about applying configuration to a system, we can reuse existing tools where they make sense, but it's also reasonable to say that we might choose to bypass them and use a tool such as Augeaus or Puppet to apply the configuration we want. +1 My point was that creating a standard *model* does not prevent us from choosing different mechanisms for the implementation. It simply hides those differences behind a standard interface[s]. Just like packagers may use different contents in their %build section but *every* package is still being built with the same rpmbuild command. Yes, I agree. Simple package installation must not require interaction. We should define that as a fundamental tenet of our approach. We need it to always be possible to have unattended or scripted operation. +1 Yeah, obviously we'll need to maintain simple distinction about how we maintain the data. Namespacing is one option. Another might be to use an object-oriented API where we have objects associated with each service (not necessarily package...) that have configuration options specified as their attributes. OO API is fine, as long as all classes present a unified *interface*. About name-spacing/scoping: * If a package contain more than one service, the scoping may be more fine-grained/narrow than a package -- no problem. * However, if the highest level scope is a package -- than each package may simply contain its configuration definitions. [I'm talking about the configuration keys+types, not their values]. * Advantages of such a design: - When a package is installed, its configuration options are exposed (simply because its configuration definition files are there) - A package is still self-contained and fully describe its software (including the available configuration options). Extending the above, one of my thoughts on another thread on the Fedora Server mailing list is to use D-BUS for the configuration API. Among other things, we have the D-BUS object types to work with. This would mean that we can have service-specific objects with appropriately-typed options. Sounds like a great idea: * As you said we automatically gain all D-Bus goodies (including a fully developed type-system). * Also, I think we can map it to some data-driven syntax. Example: * For simplicity, let's assume each configuration item is a D-Bus property. * Than a package may install a configuration definition file: /usr/share/system-config-data/package/foo.conf-defs: D-Bus interface object property ro/rw/wo * So a generic configuration engine that read all these files, should have no trouble accessing these properties, presenting them to the user (according to their types) and then inject the user choice over D-Bus. * The packager would have to supply implementation for these objects, but we may ease this for most packages by supplying some common classes which can be easily inherited from. [obviously, this part is the toughest to get right] * A package installation register its configuration options in a system-wide database. I'm not sure this makes sense. This would require us to maintain data in two places, because zero existing packages would *retrieve* their data from this location. We'd have a duplication problem and we would also be responsible for bi-directional sync (if someone hand-edited a configuration file, we'd need to read it back into the database). I suspect my choice of words (database) wasn't so good. I didn't mean storing the configuration *values*, only the available configuration options. Perhaps calling it catalog would have made more sense. Basically, in debconf it contains a list of all possible configuration entries. Each with: * A fully qualified name (including the package it belongs to). * Type info. * Available translations. I think it makes more sense to build an API around something like Augeaus and rely on being able to read and write the configuration
Re: Fedora.next: I would like working configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/28/2014 06:48 PM, Oron Peled wrote: On Tuesday 28 January 2014 08:23:46 Stephen Gallagher wrote: Forwarding this to ser...@lists.fedoraproject.org as well. Responses inline. As I'm not on the server list (yet), I replied to both lists. If devel should be off this thread, just remove it in your next reply and I'll understand the hint. It's fine to keep it on both lists (IMHO). I looped in server@ because that's where most of the discussion is happening and I don't want these good ideas getting lost. I realize you address this below somewhat, but I want to call out that what you're describing here is the *presentation layer* of configuration, not necessarily the configuration itself. In general, the vast majority of applications keep their configurations in 1) a set of text files, 2) a project-specific database or 3) a combination of the two) If projects provide a set of tools to manipulate this configuration, that's separate from the configuration itself. As we start talking about applying configuration to a system, we can reuse existing tools where they make sense, but it's also reasonable to say that we might choose to bypass them and use a tool such as Augeaus or Puppet to apply the configuration we want. +1 My point was that creating a standard *model* does not prevent us from choosing different mechanisms for the implementation. It simply hides those differences behind a standard interface[s]. Just like packagers may use different contents in their %build section but *every* package is still being built with the same rpmbuild command. I think we're saying the same thing here with different words (see below). Yes, I agree. Simple package installation must not require interaction. We should define that as a fundamental tenet of our approach. We need it to always be possible to have unattended or scripted operation. +1 Yeah, obviously we'll need to maintain simple distinction about how we maintain the data. Namespacing is one option. Another might be to use an object-oriented API where we have objects associated with each service (not necessarily package...) that have configuration options specified as their attributes. OO API is fine, as long as all classes present a unified *interface*. About name-spacing/scoping: * If a package contain more than one service, the scoping may be more fine-grained/narrow than a package -- no problem. * However, if the highest level scope is a package -- than each package may simply contain its configuration definitions. [I'm talking about the configuration keys+types, not their values]. * Advantages of such a design: - When a package is installed, its configuration options are exposed (simply because its configuration definition files are there) - A package is still self-contained and fully describe its software (including the available configuration options). I would really like to avoid talking about packages when describing Server Roles, because I feel it's very limiting. My personal goals here are to describe *services* which may or may not map to a package. For example, one package may offer multiple services. either unique like the old inetd services or something like 389 DS or a Django app which can have multiple instances of the same service running on different ports. Conversely, we can also have services like FreeIPA, which is comprised of multiple packages that really should be configured together (though that may boil down under the hood to managing the lower-level services as well). Extending the above, one of my thoughts on another thread on the Fedora Server mailing list is to use D-BUS for the configuration API. Among other things, we have the D-BUS object types to work with. This would mean that we can have service-specific objects with appropriately-typed options. Sounds like a great idea: * As you said we automatically gain all D-Bus goodies (including a fully developed type-system). * Also, I think we can map it to some data-driven syntax. Example: * For simplicity, let's assume each configuration item is a D-Bus property. * Than a package may install a configuration definition file: /usr/share/system-config-data/package/foo.conf-defs: D-Bus interface object property ro/rw/wo * So a generic configuration engine that read all these files, should have no trouble accessing these properties, presenting them to the user (according to their types) and then inject the user choice over D-Bus. * The packager would have to supply implementation for these objects, but we may ease this for most packages by supplying some common classes which can be easily inherited from. [obviously, this part is the toughest to get right] Agreed, but hopefully we can at least work on offering a few sensible reference implementations first. A common class seems ideal, but probably too much to
Fedora.next: I would like working configurations
Hi, might be totaly out of scope for Fedora.next, but this is what I would like to get better in Fedora. If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. - If I install a Fedora-server with dhcpd, dhcpd doesn't do anything - If I install tftpd and syslinux, I don't get a working pxe-config - If I install postfix, I don't get a working mail-server - If I install Nagios, it does not monitor report anything ... I have no idea, how to change this. Debian uses some interactive stuff to create a more or less working configuration while installing a package. This resembles the Microsoft installation tools. But rpm is strictly non-interactive, so this would not work for Fedora. I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. To build a Fedora-Server which does the needed ip address management stuff for a modern network (dhcpd with dynamic bind-updates for IPv4 and IPv6 plus forwarding to the isp) is non-trivial, even for a long time admin. Perhaps meta-packages (call them roles or stacks if you like) like ipam (pulls in dhcpd, bind, ... plus some config-files) or mail-server (pulls in postfix, imap, fetchmail, ...) might be the solution. I have no idea how to do this. Combing several packages and integrating them would produce some interessting test-problems. How to avoid colliding apache-configs done by different meta-packages, ... cu romal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 01:31 PM, Robert M. Albrecht wrote: Hi, might be totaly out of scope for Fedora.next, but this is what I would like to get better in Fedora. If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. - If I install a Fedora-server with dhcpd, dhcpd doesn't do anything - If I install tftpd and syslinux, I don't get a working pxe-config - If I install postfix, I don't get a working mail-server - If I install Nagios, it does not monitor report anything ... I have no idea, how to change this. Debian uses some interactive stuff to create a more or less working configuration while installing a package. This resembles the Microsoft installation tools. But rpm is strictly non-interactive, so this would not work for Fedora. I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. To build a Fedora-Server which does the needed ip address management stuff for a modern network (dhcpd with dynamic bind-updates for IPv4 and IPv6 plus forwarding to the isp) is non-trivial, even for a long time admin. Perhaps meta-packages (call them roles or stacks if you like) like ipam (pulls in dhcpd, bind, ... plus some config-files) or mail-server (pulls in postfix, imap, fetchmail, ...) might be the solution. I have no idea how to do this. Combing several packages and integrating them would produce some interessting test-problems. How to avoid colliding apache-configs done by different meta-packages, ... cu romal What you are describing is the exact problem space we intend to address in the Fedora Server product with Server Roles. I strongly suggest reading the Server Roles section of our PRD[1] and then joining the discussion that was just started on the Fedora Server development list[2] DHCP is certainly a useful example (and called out in our PRD as one of the cases we'd like to address eventually). Right now we're focusing our intent on delivering a single end-to-end Server Role for Fedora 21. We're probably going to select the FreeIPA Domain Controller for this purpose, but if we determine that we don't have sufficient time for that, we may go for a smaller initial target. DHCP might be a good one. Anyway, your ideas are good, Robert. They line up well with what we want to do, so I very much hope you'll join the conversation (and implementation!). [1] https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Featured_Server_Roles [2] https://lists.fedoraproject.org/pipermail/server/2014-January/000717.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmqp4ACgkQeiVVYja6o6NZFwCgmg68rV9ratWZg1hg/Kkgrkei rdgAoJtiwrIZ7EF/jeWD/ENymj0npdxr =TlRM -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On Mon, Jan 27, 2014 at 19:31:58 +0100, Robert M. Albrecht li...@romal.de wrote: I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. You seem to be conflating two things. One is reasonable default configuration and the other is turning on services by default. I think the first is reasonable, but that the second is a bad idea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 01:50 PM, Bruno Wolff III wrote: On Mon, Jan 27, 2014 at 19:31:58 +0100, Robert M. Albrecht li...@romal.de wrote: I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. You seem to be conflating two things. One is reasonable default configuration and the other is turning on services by default. I think the first is reasonable, but that the second is a bad idea. He's not suggesting turning services on by default just by installing pacakges (I don't think). I think his request here is similar to our Fedora Server Roles idea where there are special packages (possibly meta-packages) that are separate from the simple installed bits. So you might have the server-role-dhcp package that 'Requires: dhcp' but also provides either a default (and reasonably-secure) configuration or some mechanism to interactively configure and deploy a DHCP server. So if someone installed the 'dhcp' package on its own, this would not autostart it. However, if someone deployed the DHCP Server role, that should be considered a sufficiently intentional action to start it. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmrQwACgkQeiVVYja6o6MG8QCgsQDPrJx7IhGcKK0TfiruFxhJ 1BEAoKo3ze3+vEzGUZ9L3tIDoa4K1lbQ =vGV/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Most of the services you described do have a working configuration but the service is not turned on. You are right though, when you install a Windows CA it's ready to go. In regards to DHCP, the dhcpd.conf file has a commented sample that needs to be edited and then turned on. Is this what you are looking for? On 27/01/14 14:33, Chris Adams wrote: Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Hi, dhcpd is just an (maybe bad) example. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... and double this stuff for IPv4 and IPv6. I used this only as an example to show that nearly all daemons are not ready-to-run. cups and apache are not sharing user-groups with samba and nagios, ... Integration of services is often possible, but not done when doing a fresh Fedora installation. What I would like is more integration to produce a working server. If I create a user group, it should be known in all installed services. This might not be restricted to servers: all audio-components are there to do some professional work: jack, pulseuaudio, alsa, Audacity, plugins, ... but I have to fiddle them together myself. cu romal Am 27.01.14 21:01, schrieb Dan Lavu: Most of the services you described do have a working configuration but the service is not turned on. You are right though, when you install a Windows CA it's ready to go. In regards to DHCP, the dhcpd.conf file has a commented sample that needs to be edited and then turned on. Is this what you are looking for? On 27/01/14 14:33, Chris Adams wrote: Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Hi, if the server sits in a RFC1918 network (192.168.1.0/16), has a static IP and a configured gateway and DNS, it might be reasonable to assume, the dhcpd should operate in this range and set the options for DNS and gateway accordingly. At least the installation could produce a sample-config-file, which reflects the running configuration. Also it could to talk to firewalld to configure the firewall. But I used dhcpd just as a (maybe bad) exmaple to explain my problem. cu romal Am 27.01.14 20:33, schrieb Chris Adams: Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Hi, He's not suggesting turning services on by default just by installing pacakges (I don't think). I think his request here is similar to our Fedora Server Roles idea where there are special packages (possibly meta-packages) that are separate from the simple installed bits. So you might have the server-role-dhcp package that 'Requires: dhcp' but also provides either a default (and reasonably-secure) configuration or some mechanism to interactively configure and deploy a DHCP server. So if someone installed the 'dhcp' package on its own, this would not autostart it. However, if someone deployed the DHCP Server role, that should be considered a sufficiently intentional action to start it. Perfect. You are a mind-reader :-) cu romal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On 27 January 2014 14:01, Robert M. Albrecht li...@romal.de wrote: Hi, dhcpd is just an (maybe bad) example. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... The reason why these daemons are not ready to run is that when they used to be ready to run, they caused problems with whatever environment was already there. We used to ship tools which could do what was thought to be a reasonable job of configuring them but it quickly turned into that no one does their environment the same way and doesn't want to be told to do it like anyone else. Being ready out of the box though is not always desirable. I have regularly seen networks go offline because someone installed Microsoft DHCP but not taken into account the already configured DHCP boxes. [The same with AD and other items...] Being ready to work works well in small environments but quickly causes more headaches in more complex ones. Having to account for that is where most of the things that need the admin to really know what is going on in their environment and being able to translate to making the computer do what is needed versus what is wanted. It isn't an insurmountable problem, and I guess the Server Roles or something similar will help do that but it will take a lot of work to get there. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On 27.01.2014 22:01, Robert M. Albrecht wrote: Hi, dhcpd is just an (maybe bad) example. It is good example. See dhcp configuration in your home router - it requires some attention. Then try some Cisco or HP router and its dhcp configuration. This smart devices are not so smart to work for everybody out of the box. This is also true for Linux versions of this daemon. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... and double this stuff for IPv4 and IPv6. You can disable IPv6 if you don't need it. How can any software possibly know your network address before you enter it during installation? How would dhcpd daemon know IP ranges you want to lease to hosts on your network? Read your mind? I used this only as an example to show that nearly all daemons are not ready-to-run. cups and apache are not sharing user-groups with samba and nagios, ... Because I don't want that functionality. If it's what you need, please learn how to do it and just do it. No one is preventing you from doing that. Integration of services is often possible, but not done when doing a fresh Fedora installation. Because different people need to integrate different things. But it's not entirely true what you said, take a look at FreeIPA, perfect example of integrated service. What I would like is more integration to produce a working server. If I create a user group, it should be known in all installed services. It is... or you're doing something wrong. What kind of user accounts are not recognized by what software? This might not be restricted to servers: all audio-components are there to do some professional work: jack, pulseuaudio, alsa, Audacity, plugins, ... but I have to fiddle them together myself. What? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On Jan 27, 2014, at 2:16 PM, Stephen John Smoogen smo...@gmail.com wrote: The reason why these daemons are not ready to run is that when they used to be ready to run, they caused problems with whatever environment was already there. We used to ship tools which could do what was thought to be a reasonable job of configuring them but it quickly turned into that no one does their environment the same way and doesn't want to be told to do it like anyone else. At least with something cleanly installed, I'd like it to work with Fedora's best practices in mind, understanding what is best practices is often in flux. One thing I see Fedora doing is helping me sharpen the saw, not do things my way. Best practices doesn't necessarily mean on by default, however. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On 27.01.2014 22:05, Robert M. Albrecht wrote: Hi, if the server sits in a RFC1918 network (192.168.1.0/16), has a static IP and a configured gateway and DNS, it might be reasonable to assume, the dhcpd should operate in this range and set the options for DNS and gateway accordingly. Imagine Linux box with three NICs, each on different network. To simplify things let there be NAT and and two public addresses (some kind of failover.) What interface should dhcp server operate on? What address pools should be used there? It can't be easily deduced without admin intervention. Too much use cases. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote: ... or some mechanism to interactively configure and deploy a DHCP server. IMO, that's exactly the crux of the matter. Most non-trivial services requires some administrative decisions to configure them properly. Since rpm does not allow interactive query of the user (IMO rightfully), everybody implement custom solutions: * Some custom scripts (e.g: freeipa-server-install) * Only hand configuration (e.g: dhcpd) * Some web-based PHP configuration (many php web-applications that look for an easy solution to a tough problem and forget about security along the way...) Just like packaging systems implemented a common framework to install software, we need a common framework to *configure* it (at least base configuration if the full configuration management problem is too tough). My suggestion is to look first at the debconf abstract model. Let's start with one design decision which I think we should avoid: * Debian triggers debconf operations from the package installer. This means package installation is potentially interactive (not good). I think the configuration mechanism should be explicitly called from elsewhere. (e.g: when administrator want to activate/configure the service). But now, let's look at the good properties which we can learn from: * All configuration options are name-spaced (in debconf it's done by package name) * Each configuration option has specific *type* info (string, boolean, multi-select, etc.) * A package installation register its configuration options in a system-wide database. * This also contains end-user visible text for each option including i18n. * The debconf database may be populated via different front-ends: GUI, TUI, command-line, web-based (experimental), preseed (for kickstart install). * All front ends need only understand the generic types of the options. (I.e: they provide generic configuration UI widgets which aren't modified when new packages/options are added) * The debconf API allows fetching any option from the database and the values of these options are used to configure the actual software. Note: I tried to abstract away the properties, because I don't think the debconf *implementation* fits what we need. However, the model shows how very different packages can use a common framework for basic configuration, just like RPM shows how very different packages can use a common framework for installation. Having such a framework would allow a *standard* way of configuring a set of packages for specific roles. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron I love deadlines, especially the whooshing sound they make as they go by. -- Douglas Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
