Re: ModemManager MBIM QMI USB_ModeSwitch
Hi, I will update tha package on next weekend. cu romal Am 09.08.14 um 10:11 schrieb poma: On 09.08.2014 09:56, Matthew Miller wrote: On Sat, Aug 09, 2014 at 08:35:12AM +0200, poma wrote: These two are waiting for more than two months!? usb_modeswitch-2.2.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1059671#c5 Reported: 2014-05-30 usb_modeswitch-data-20140529 is available https://bugzilla.redhat.com/show_bug.cgi?id=1059672#c5 Reported: 2014-05-30 Take a look at http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Then I'm also going on vacation for at least 2 months! :) http://hosted.akibraun.com/g/fistbump.gif YEHA poma -- 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, 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 in 2014 -- Big Picture and Themes
Hi, * Although it's certainly not the only reason, Fedora as _solely_ a hobbyist desktop is not ideal for an upstream for RHEL server and cloud products. No other system can be reinstalled / upgraded every six months. That single fact IMHO kills all other use cases. If I need a stable Fedora-like server, I get CentOS. It's kind of a Fedora-LTS. * General trend in Linux towards the base distribution being boring and not mattering. I asked several dozen different people at a gigantic Amazon conference why everyone was using the distribution they chose instead of Fedora, and the answer was almost universally oh, I don't care; that's not really an interesting question because there's nothing important at that level. All (of the big) distros are mature today. At the early days one chose his distro by drivers, by installation-tool, by packages, ... Nowady every distro has a working installer, has a bazillion packages, ... they basically all work. So non-technical topics become more relevant: is there a LTS-release, can I start with a free(beer) distro like centos and later change to a paid-support-modell (RHEL) without rebuilding all my configs and apps, how good is the documentation, ... The real innovation is happening on the desktop: power management, Wayland, Mesa, wifi/3g/4g, color-management, pulseaudio, ... Now, that might not be really _true_, but it's definitely an increasing perception. How can we either fight that perception, or make sure that Fedora expands to also do work in the interesting space? I don't know anything about the statistics on Fedora contributors and their jobs. But if there are lot of hobbyists, students, ... these people are not able / interessted in large enterprise stuff like OpenStack, ... they work on devel-tools like languages and desktop-stuff, that's what they are using. If Fedora want's more innovation in those topics, Fedora must possibly reallign the devel-community. Most enterprise-project like libvirt, freeipa, Spacewalk, ... are done by Redhat-people ? Or am I totaly mistaken there. 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 in 2014 -- Big Picture and Themes
Hi, what is a role? Is database-server a usefull role? Or would that go more to owncloud-server or joomla-server ... This would then pull all packages in. And if Owncloud supports several databases, Fedora should make a choice and install only one of them. A user which cares so deeply to make a decision which database he want's will install it manually anyhow. Fedora is making these choices on other instances: you get x.org and not wayland. You get gcc and not llvm. You get systemd and not upstart. cu romal Am 28.01.14 19:06, schrieb Tom Hughes: On 28/01/14 17:33, Matthew Miller wrote: On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote: I think the reason that people have trouble defining what Fedora Server might mean is that it simply doesn't make a huge amount of sense as a thing. Yes, that has traditionally been the stumbling block. But have you looked at what the Fedora Server working group is coming up with? The roles stuff? I have, though I'm not sure if I just failing to get it or something but I don't see anything there that looks especially useful to a server administrator. Other than pulling in a group of packages it's not really clear to me what a role does for me, and I suspect that defining roles that are generally useful without pulling in more than people really want will be hard - the classic example being the database server role that was included in the examples and which was going to pull in both postgres and mysql. Well normally I want one or the other, but not both... Obviously that can be fixed by having mysql server and postgres server roles but at one point do you wind up with one role per package and basically back where you started? If I recall correctly there was also some talk of having each role provide some sort of configuration/management interface that plugged into a web console but frankly that's the last thing I want on a server I'm looking after. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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
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
