Need help with a package review - BZ#2259602
Hello, Could someone please help to review this package request? -> https://bugzilla.redhat.com/show_bug.cgi?id=2259602 Thank you. --- -Prasad -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Hi, On Friday, 19 August, 2022, 03:05:03 am IST, Ben Cotton wrote: >I just completed the first run of FESCo's newly approved Inactive >Packager Policy[1]. Packagers that have been identified as inactive >have a ticket in the find-inactive-packagers repo[2]. One week after >the F37 final release, packagers who remain inactive will be removed >from the packager group. > >For the curious, here are the stats from today's run: > >2550 users checked >913 of those had no activity on src.fedoraproject.org or pagure.io >835 of those had no activity in Bodhi >812 of those had no activity on the mailing lists >606 of those (~24% of packagers) had no activity in Bugzilla. > * Interesting numbers there. * While I get that such pruning from time to time is generally good. What happens to the packages orphaned by removing inactive packagers? * Removing orphaned packages may not be easy, as other packages may depend on them. Thank you. --- -P J P http://feedmug.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Security Team
Hello Marek, On Tuesday, 3 November, 2020, 5:38:39 am IST, Michael Catanzaro wrote: >On Tue, Nov 3, 2020 at 12:53 am, Marek Marczykowski-Górecki > wrote: >> How are in practice security issues handled in Fedora? Is there an >> active security team to help patching those in timely manner? Or is it >> responsibility of individual package maintainers only? > >Red Hat Product Security is responsible for monitoring CVEs and >reporting bugs when they determine that a CVE affects Fedora. Fixing >the CVEs is the responsibility of individual package maintainers. Many >maintainers respond to bugs expeditiously, but also it's pretty common >for maintainers to ignore the bug reports filed by Product Security. >Sometimes this has unfortunate results. It really differs on a >component-by-component basis. * Right, Fedora package CVEs and relevant bugs are filed by Red Hat Product security team. * CVEs/bugs are fixed in the upstream sources first. Fedora package maintainers do rebuild of the package with released fixes. * Often, Fedora package maintainer is also an upstream developer/maintainer. It helps to fix issues sooner. * Fedora security team was more looking into auditing and improving Fedora distribution security via safe default configurations and policies etc. While also following up with maintainers for fixing CVE bugs sooner. Thank you. --- -P J P http://feedmug.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
DevConf.IN 2019 Inviting Speakers - CFP Open
Hello, The annual DevConf.IN conference is here again! -> https://devconf.info/in/ We are glad to announce that CFP for DevConf.IN 2019 is now open!! :) Event Dates: 2 - 3 August 2019 Venue: Selection underway - TBA , Bengaluru, KA, India. Important dates -> CFP closes: May 1st, 2019 -> Speaker confirmation: June 1st, 2019 -> Schedule announcement: July 1st, 2019 We cordially invite you to submit a proposal to speak at DevConf.IN 2019. This is the third edition of DevConf.in conference where free and open source software communities and developers meet, learn, and hack on FOSS projects. DevConf.IN 2019 is organised and sponsored by Red Hat Inc. We invite speakers from various backgrounds and roles, including developers, administrators, engineers, DevOps practitioners, quality engineers, technical writers, project managers, and more. If you’re a FOSS project contributor, you’re a potential speaker! While submitting the proposal, you need to choose a theme that the talk/workshop belongs to. Themes for this year are * TRENDING TECH : * AI, Machine Learning, Block Chain, IoT, Mobile. * Storage and Networking * Cloud Native Storage, Software Defined Storage, Storage Management, Distributed file system, datastores, Big Data, NFV/VNF, Fast data path acceleration, OVS/VPP and DPDK, , network debug analysis, Software Defined Networking, OVS offload/full offload, performance benchmarking, NFV * Open Hybrid Cloud * Multi Cloud, Automation, OpenStack, Kubernetes, Serverless, Microservices, Containers, OpenShift/ PaaS, Hybrid Cloud management, Operators, CNI, Virtualization, Kernel, Service mesh * Developer Tools * Container Tooling, CI/CD, DevOps, Code Editors, Cloud native IDE, CLI, Local Development for containers, Language Runtime, Debugging/Tracing, Testing * FOSS Community and Standards * Community Trends, governance, licensing, contribution, Leadership Agile * White Paper/ Academic Research * Computer Science Engineering, New algorithms, Protocols, Experimental/Future networks, Data Modelling, Security, Natural Language Processing-NLP * Design * Security * QE * DevOps * Documentation * Security/Data Privacy These focus areas are the common and integral part of all themes We are looking for talks and workshops which appeal to the beginner, intermediate and advanced participant in community projects. The CFP is NOW OPEN! Ready to submit your proposal? Visit -> http://devconf.in/ Questions? Please write to us at Thank you. --- -P J P http://feedmug.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
DevConf.in 2018 inviting speakers - CFP open
Hello, Please see -> https://devconf.info/in/cfp CFP closes: 4 May 2018 Accepted speakers confirmation: 4 June 2018 Conference Dates: 4, 5 August, 2018, Bengaluru, India We invite you to submit a proposal to speak at DevConf.in 2018. This is the second DevConf.in conference where free and open source software communities and developers meet, learn, and hack on FOSS projects. DevConf.in 2018 is organised and sponsored by Red Hat. We are looking for speakers from all types of roles, including developers, administrators, engineers, DevOps practitioners, quality engineers, technical writers, project managers, and more. Each speaker while submitting the proposal is requested to choose a theme that the talk/workshop belongs to. Few of the themes for this year are - Linux - Middleware - Virtualization - Storage - Cloud and mobile technologies - Containers - Fedora - And much more. You can find the full list of suggested themes in the CFP form. We are looking for both advanced and introductory talks and workshops. On the second day of the conference, Sunday 5 August 2018, we will be running a track of workshops, including those at an introductory level. We have the benefit of having a mixed audience of professionals and students and we don’t want to leave anyone out. If you’re interested in submitting multiple talks, please try to limit your suggestions to your best ideas. The CFP is NOW OPEN! Ready to submit your proposal? Visit devconf.in/cfp Questions? Please write to us at i...@devconf.in Thank you. -- - DevConf.in 2018 organising team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Python-cvss licence change
Hello, -> https://github.com/skontar/cvss -> https://admin.fedoraproject.org/pkgdb/package/rpms/python-cvss/ -> https://www.first.org/cvss/calculator/3.0 Recently I packaged the cvss Python modules for computing Common Vulnerability Scoring System(CVSS) rating for security issues. It contains CVSS v2 and v3 computation utilities and interactive calculator compatible with both Python v2 and v3. Its licence has been changed from GPLv3+ to LGPLv3+. -> https://github.com/skontar/cvss/issues/6 Thank you. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Hannes Frederic Sowa
Hello Hannes, > On Thursday, 18 February 2016 3:11 AM, Hannes Frederic Sowa wrote: > back to the community. After last weeks meet-up with my team and > especially Lubomir during devconf.cz, I finally decided to start this. ... > At first, I will try my luck with a probably more simple package, GNU > datamash - <https://bugzilla.redhat.com/show_bug.cgi?id=1126308>, were I > am waiting for the one week heads-up time to pass, so I can take over > the package after a stall from the submitter. After that I will submit a > package for iovisor-bcc - <https://github.com/iovisor/bcc> - which > provides tooling around the new eBPF infrastructure in the kernel. This > might eventually need some fixes upstream first so the build process is > streamlined within Fedora. Cool, sounds like a plan! Welcome aboard!! :) (just shout if you need anything) --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1287607 Thank you for filing the bug. > * howto prevent dnsmasq from starting (right now I'm just manually killing > it for testing) # systemctl disable dnsmasq > * howto get domainname set automatically from dhcp Dhcp configuration manual should help with that. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
Hello Neal, > On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote: > For example, when I'm at work, I can access hostA.work.com > where resolving hostA only works by talking to dnsserverA.work.com, > which was setup by the usual dhcp and then when I'm at home > > google.com is resolved as normal, using my ISP's dhcp to configure dns. > And this must work without the user ever editing some unbound config file. Yes, it does work that way. The proposed solution(tools) is available in current Fedora repositories and is easy to set-up and test. -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test Please let us know if you face any difficulties. Thank you. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
Hello Vit, > On Tuesday, 1 December 2015 1:45 PM, Vít Ondruch wrote: > > If I am not mistaken, this is at least 3rd time this change is proposed. > Can somebody post some short summary what was changed, that you believe > it will be successful this time? True, it was postponed couple of times because few implementation issues were not resolved properly. There wasn't consensus about how the proposed solution would interact with other components(ex. NM, Gnome shell) on the system.[*] We have managed to sort out those differences and hope to resolve implementation issues to build a strong solution. [*] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Thank you. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
Hello Russell, > On Tuesday, 1 December 2015 12:21 AM, Russell Doty wrote: >> Is DNS by itself sufficient, or should we also address other network > facing capabilities with security impact such as secure time? Yes, we could do that. But that would have to be an independent Change request. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnssec-trigger + GNOME + NetworkManager integration
Hello, On Tuesday, 23 June 2015 10:13 PM, Tomas Hozza wrote: Now we know that we have at least 3 components on the system, that are trying to do the same thing - Captive Portal detection: - dnssec-trigger - NetworkManager - GNOME Shell We don't have a problem with turning the detection off, however we need to agree on system-wide solution that works properly. True, couldn't agree more. +100 On Wednesday, 24 June 2015 12:47 AM, Michael Catanzaro wrote: Yes, that's correct. If NetworkManager's ConnectivityState is NetworkManager.ConnectivityState.PORTAL, then we launch a small (250 lines of code) GTK+ app with a WebKitWebView [1][2]. I expect that as long as NetworkManager's existing connectivity API is not broken, GNOME should be fine. If Gnome too depends on NetworkManager APIs, I wonder why is it separately conducting captive portal detection on its own? IMHO NetworkManager is best placed and best suited to conduct network probes and notify other applications via its APIs. NM could be our one solid system wide solution for everything that is network. --- Regards -P J P http://feedmug.com -- 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: F23 System Wide Change: Default Local DNS Resolver
Hello Miloslav, On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač m...@redhat.com wrote: We’ve had earlier conversations about whether the resolver being used (local, remote, container host) is trusted to perform DNSSEC validation. How is this resolved? The Change page AFAICS doesn’t say. Do you e.g. plan to have a configuration file which tells libc/and other applications dealing with resolv.conf directly to know whether the resolver can be trusted for DNSSEC? Or is perhaps the design that any resolver in /etc/resolv.conf is always trusted for DNSSEC, and sysadmins need to ensure that this is true if they use a remote one? Ummn...not any resolver in resolv.conf, but 127.0.0.1 is considered to be trusted. The proposed change is also to ensure that resolv.conf always has only 127.0.0.1 entry in it; And nothing else. Configuration changes to indicate 'trusted' character of a resolver was proposed to upstream glibc, but that is yet to be resolved properly. - https://www.sourceware.org/ml/libc-alpha/2014-11/msg00426.html --- Regards -P J P http://feedmug.com -- 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: F23 System Wide Change: Default Local DNS Resolver
Hello Vit, On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote: I hope that I won't need to do this steps manually after F23 installation, otherwise it could be hardly called default. So when there will be available final version which does not need any additional configuration available for testing? As per F23 schedule, it's post 28 Jul 2015 - https://fedoraproject.org/wiki/Releases/23/Schedule --- Regards -P J P http://feedmug.com -- 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: Need to contact rubygem-activesupport EPEL branch maintainer
Hello Jan, On Monday, 20 April 2015 1:08 PM, Jan Rusnacko wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1127228 Try pinging on IRC or direct mail, I found he rarely (if ever?) responds to bugzilla spam. Oh, that's not good. I've sent him an email, let's see. Thank you. --- Regards -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Need to contact rubygem-activesupport EPEL branch maintainer
Hello, Please see: - https://bugzilla.redhat.com/show_bug.cgi?id=1209124 Does anyone know where to contact Mr Michael Stahnke, the rubygem-activesupport EPEL branch maintainer. The package needs to be updated with few fixes. Thank you. --- Regards - P J P http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wednesday, 14 January 2015 10:44 PM, Simo Sorce wrote: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. Sorry, but what is the point of this operation, wrt auth with keys issue ? Well, it can be used it to export to other machines. It'll require you to login as non-root user first. Being able to authenticate as root right after installation would be the requirement for me. Right. But how would you inject a key for that? If you must have only 'root' account in your set-up, remote root access could be enabled by default. Feature page lists ... Omission of such user account should prompt user if they wish to enable remote 'root' login, and set the parameter appropriately. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hi, On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. Except you have no mechanism to inject a key at installation time, Sure. Could you please elaborate how would you like this key to be injected into the 'root' account? Feature page does have a listed workflow change: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. It'll help if you could add your details to the ether pad, for later reference. here - https://www.piratepad.ca/p/ssh-remoterootloigin The intention may be not, then I'll call it poor execution/planning and still oppose this move *at this time* unless there is proof we address the usability problem first. We are still in the proposal state, not execution yet. IMO, before we request the respective upstream developers to provide the needed functionality, we need to state and agree on the usability requirements. That'll be useful in the evaluation of the feature by the FES committee too. Otherwise it's a chicken-and-egg problem. I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Thank you. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello Simo, On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote: Sorry this is false. You got enough emails telling you this change is undesirable, that's the definition of opposition and means you have no _consensus_. IIUC, that was for disabling remote root access completely with 'PermitRootLogin=no'. As the 'PermitRootLoing=without-password' option seems more preferred. As for the emails, many folks have also said that it is a useful change. IMO, the ones opposing are those who fear their current setups/practices would break. Because they need remote 'root' access in their set-up. Which is a genuine use-case. And to support it, we could provide an option to enable remote root access with 'PermitRootLogin=Yes', based on the the user's response to Anaconda at install time, as was suggested in previous email. However, let's not assume _all_ Fedora users have this use-case. - IMHO, the change helps to harden Fedora systems and raise the security bar a notch higher. It is similar to how we run services as non-root user instead of 'root' user. - The proposed change of using ssh keys for remote 'root' access introduces that mechanism to a wider audience, which in turn would help increase its usage in the future. Hence bring more value in the long term. - IMO, it is beneficial to supply hardened default configurations, because they protect maximum users and have greater impact, than otherwise. Security is not a feature, it must be available by default. - Of course that does not mean we overlook the usability aspect. As said before intention is _not_ to trouble users, but increase their safety as much as we can. Thank you. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello Dennis, On Tuesday, 13 January 2015 10:05 PM, Dennis Gilmore wrote: There is no consensus on that. Well, no opposition as such either. How is it done otherwise, do we conduct votes to establish consensus, is that a usual practice? I do not do enough installs that I use kickstart so can not put a key in place. On a freshly installed system I have to log in as root with a password to do configuration. I strongly suspect that I am not alone here. You need to talk to the anaconda team and work out a plan to deal with all the different options. up to and including having the current defaults exist when only a root account is configured with only a password for authentication. I suspect that to properly support making changes here it needs to be strongly tied into anaconda changes that manage the initial sshd config file. True. I plan to talk to them about the proposed workflow changes; One of which caters to the case wherein only 'root' user is needed. Omission of such user account should prompt user if they wish to enable remote 'root' login and set the parameter appropriately. OR Other way could be to just enable remote 'root' login when no non-root account is created by the user. Let's see, they might have other suggestions. ---Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tuesday, 13 January 2015 4:24 AM, Volker Sobek wrote: Maybe this difference can be addressed together with what ever is decided upon in this discussion? I think having some consistency here would be good. IMO, the install image consistency issues need to be handled separately and could not be clubbed with this feature/change. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello, Please see: (shared by 'fenrus02' on IRC) - https://stribika.github.io/2015/01/04/secure-secure-shell.html Here are few more recommendations for sshd(8) configurations, mostly pertaining to encryption algorithms. Does it make sense to incorporate any of the suggestions from there? --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello Miloslav, all On Tuesday, 13 January 2015 10:26 AM, P J P wrote: So, we do seem to have consensus(at least no opposition) for 'PermitRootLogin=without-password' option. I'll update the feature page with it and details about the specific use-cases. I have updated the feature page with the due changes as discussed and suggested so far. Please see: - https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no Please feel free to edit the feature page as required. If you find something amiss or unclear, please let me know, I'll fix it. As always, your comments and suggestions are most welcome! :) Thank you. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello, On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote: Earlier in the discussions I was told that this is not really an issue: in production, about every server with remote access also has a KVM. Often not the case in small business or third party hosted environments. Without remote ssh, box is unmanageable. Even if you want to do key-based authentication rather than password, you still need to use password initially to get the key onto the remote box. If you use cloud-init you can specify an initial public key that it inserts against, or even auto enrol it in a central auth system like IPA and hence not ever need a password. So, the major issue(or blocker should we say?) is the virtualized deployments. If there is no solution in sight, maybe last resort is to enable remote root login, possibly in the '%post' install section of the kick-start file. Does it seem like an appropriate solution? --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote: You are (instead of completly mitigating), only raising complexity a little bit (ie not completly avoiding), which is what is Security through obscurity about (ie. by hiding source code, the attacker only solve more complex problem - debugging machine code). One more time: The system can be cracked by BF attack only if there is a weak (root) password. Sure. As guessed, you misunderstood the intention. The feature is _not_ a remedy against brute force attacks. But it is a remedy for keeping such attackers from gaining 'root' access on remote machines. The feature says, ...Disabling remote root login by setting PermitRootLogin=no would help to harden Fedora systems, moving it an inch closer towards 'secure by default' future. Users can have non-root accounts with weak passwords too, yet disabling remote root login keeps an attacker a step away from getting full control on a system... The feature helps to _harden_ Fedora systems. Same as filtering traffic via firewall or restricting undue access via SELinux etc. If you disable remote root login (bacause users are using weak crackable password), you are saying to the user: Happily use simple password because you are safe even that!. And because when admin password could be simple then the user password will be more simpler (this is average-user-logic) and the BF against the system will succeed more easily (even the login name will need to be guessed or picked by another way). So your solution is potentionally more dangerous than current situation. That is a lot of speculation and hypothesis. In now way does this feature imply or indicate to users that they can use weak passwords. If you want to avoid the problem (ie avoid BF crack-in), disabling remote root login is not the right way, this is simply not enough, this does not solve the problem. There are better solutions I wrote about already (prefferrably to not expose SSH to the wild by default). Again, issue being addressed is not of brute force attacks. But that of such attacks resulting in gaining 'root' access to remote machines. They are two distinct issues. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
Hello, On Monday, 12 January 2015 4:09 PM, Ian Malone ibmal...@gmail.com wrote: On 12 January 2015 at 09:20, Milan Keršláger milan.kersla...@pslib.cz 4) Blocking root access means forcing admins to log as normal user and then do su/sudo and providing root password, which is far less secure than disable root password authentication and allow login to root with SSH key only, because password could be easily stolen (private key is never send to the net so is more safe). It is only more secure if you assume normal user password ssh is allowed. It shouldn't be either, it should be ssh key. If you're allowing password login on any account then you're less secure, even without discussing sudo. I understand. As said in the other thread, how we restrict remote root access is negotiable. Though IMHO, we are not yet ready for purely keys based authentication and disable password authentication altogether. In fact, disabling remote 'root' access could be the first step in that direction. Ie. if we start using keys for remote 'root' access. 6) Because all I wrote above, disabling root login is Security through obscurity and THIS NOT IMPROVE SECURITY! See https://cs.wikipedia.org/wiki/Security_through_obscurity and 5) above It's not really. Security through obscurity is design or implementation (as outlined in the English version of that wikipedia page). What this is is somewhere between security in layers and security in extended keys. User account names can be discovered and don't add many bytes compared to a secret key, on the other hand it should be easy to spot brute force attempts on user name. And not every user account on a system has sudo access, of course you can try local exploits once you have a shell, but that is still better than hanging direct root out as a big target to attack. Layers. Yes, nice term, security through layers. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello Milan, On Monday, 12 January 2015 3:11 PM, Milan Keršláger wrote: No, this is not good idea as I wrote few minutes ago because it does not improve security, it just provide feeling of better security, see: https://en.wikipedia.org/wiki/Security_through_obscurity I disagree. First of all, there is no _obscurity_ in it. Obscurity would have been if we just changed name of the 'root' user to something else, say Admin/Superuser/Batman etc. This feature _restricts_ remote root access to a machine. It is a preventive measure; Just like having SELinux or firewall or disabling services which are not used. Look at it as being analogous to two factor authentication. It involves two steps to gain remote root access to a machine, instead of one. This preventive measure can thwart real brute force attacks. Which is a net gain in terms of safety to users. Disabling root loging does not solve the problem and it profides only Which problem? It seems you've different understanding of its purpose. On Monday, 12 January 2015 4:18 PM, Francisco Alonso wrote: That's not security through obscurity. It's a way to limit the exposure to a brute force attack with an a privileged account. Also this allows the user uses a different account so remote attacks that user is unknown and can not be used to brute force delimiting more exposure. Exactly! Thank you.--- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote: I don't see how this is the case. All we have done is move the first line of the root-kit script to calling sudo via the password that was used to open the account up. Since many of Linux systems are single user boxes.. it is most likely going to work. If it fails then the majority of them just dump the warning email in /var/spool/mail/root which never gets read (from the number of boxes I have had to clean up). Sorry, I didn't get it. Running root-kit script implies you already have access to a machine. And the user has sudo(1) access enabled. And from looking at the sophistication of various worms these days.. they are a lot smarter about guessing who owns the box and then trying various smart choices (since Fedora will select ssmoogen as my name it has shown up more often in brute forces by systems which I own). That's possible. But the proposed feature is not meant to address this issue. I was going to say it is an informed speculation.. I have actually had to interview various people about weak passwords and why they chose them and the largest excuse is Well I don't need to have a strong password for this.. its not like its root. Yes, that is quite common. Which is precisely why we need to set hardened default configurations. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tuesday, 13 January 2015 1:10 AM, Stephen John Smoogen wrote: Sorry if I am misunderstanding but the feature is to address brute forcing the root account so that they do not get root access to the server. Right. I am saying that this isn't a speed-bump because they are already trying to brute force all the accounts on the system and so if they get one, they will become root as they already have the password for the account. Thus I do not see how it solves the first problem. Well, it prevents the direct brute-forcing of root accounts. The feature does not address brute forcing of the non-root accounts and its further implications. Secondly, usage of ssh keys for remote 'root' access, with 'PermitRootLogin=without-password' would provide better returns in the long term. I do not disagree. I just think that the sophistication of the malware robots is high enough that saying the above does not help hardening without further changes. [Adding a password creation tool to anaconda and gnome-first-boot to help people create 'stronger' passwords would seem to do more in hardening.] They already have that, no? When you set password, it shows a bar meant to indicate password strength, IIRC. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Tuesday, 13 January 2015 3:06 AM, Miloslav Trmač wrote: (The general theme of this mail: Being flexible is fine, and establishing this through this discussion is great; however, ultimately the Change proposal needs to document the _specific outcome_ of that discussion.²) I understand, I'll do that. “Can be” or “will be”? How? It is vaguely worrying that the Change proposal explicitly lists only the most trivial task to do (change a sshd.conf option) and is only fairly generic about how other parts of the OS and users need to and/or will adapt. Well, part of it was due to unknown use-cases of how users would be affected by this change. Otherwise, immediate straight forward effect is that users would have to create use non-root accounts first. I've tried to collate more details here - https://www.piratepad.ca/p/ssh-remoterootloigin “Could conditionally“… With my FESCo hat on, during the Change Checkpoints FESCo will need to know whether the Change is sufficiently complete or whether to fall back to the contingency plan. Having a “Could conditionally” nailed down to yes or no would prevent general unhappiness if the respective package maintainers thought that they have done the right thing and FESCo during review suddenly decided that the right thing is the opposite. Right, I understand. It's 'could conditionally' because it's still early stage proposed change in workflow. So this proposal only helps if we hope that a bot won’t try the right user name; calling this security by obscurity is not too wide off the mark. I beg to differ here a little. Because nothing is stopping them from trying non-root accounts now and even with 'without-password' option, nothing changes for non-root accounts. The proposed change and use of 'PermitRootLogin' option is only to restrict remote 'root' access. IMO that's not obscurity. So, we do seem to have consensus(at least no opposition) for 'PermitRootLogin=without-password' option. I'll update the feature page with it and details about the specific use-cases. Thank you. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello Paul, On Monday, 12 January 2015 11:18 PM, Paul Wouters wrote: What if I told you Neo, that there are no strong passwords? Passwords are weak. Some are less weak than others. I'd rather teach people to use ssh keys for remote access and only restrict passwords to console/physical access. That would be a good security lesson to teach. Sure, I'm all for it. Thirdly, as said in another thread, if we resort to using keys based authentication for 'root' account, it would lead to people using same mechanism for other accounts too. Excellent! even less password guessing possible! Exactly! And again, ignoring the collateral damage. As people suggested, keep ssh key based root logins allowed. Sure, that's absolutely fine with me. It seems maybe you missed my earlier email wherein I said, how we restrict remote 'root' access is negotiable. - https://lists.fedoraproject.org/pipermail/devel/2015-January/206224.html So 'PermitRootLogin=without-password' is good too. You can accomplish disabling password based remote root logins by disabling password based remote root logins: PermitRootLogin without-password This matches exactly what the feature is supposed to protect against - bruce forced password attacks against root. I have not heard anyone in this thread yet saying this is unacceptable, except for your vague claim of 'it would lead to people using same mechanism for other accounts too' (which I interpret as good, not bad) He..he..yes, even I meant it as an added advantage. As said before, 'PermitRootLogin=without-passoword' is fine for me too. :) So, if everybody agrees with 'PermitRootLogin=without-password' as the _default_ sshd(8) configuration, maybe we could discuss about other workflow issues, that might crop up as result. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Monday, 12 January 2015 10:06 PM, Milan Keršláger wrote: No. It improves nothing. This is step backward. It gaves bad signal to the user (strong root password is not needed). Wrong interpretation. It does not mitigate the BF attack. The original and main reason was to mitigate BF even P J P p...@fedoraproject.org told us here that not. No! Again, intention is to keep malicious users from gaining 'root' access via BF attacks. It is quite similar to why we run services as non-root users, instead of root. If at all break-in happens, it is still a non-root user. The PJP told us that this is like SELinux or firewal. But firewall block all trafic. But SELinux does not allow to obey the rules it raises. And PermitRootLogin=no still allows BF Which part of 'PermitRootLoing=yes|no' says anything about what to do with non-root account? It is not a mitigation for brute force attacks. The option merely says whether to allow remote root login or not. (which is hard to prove as I demonstrated before because it will lead to use much less quality passords for root and normal users too). That's a hypothesis. If you really want to improve security and mitigate BF attacks against root, do this: A) do not run SSHD by default That's a non-option. B) install a script by default to bann repeated login failures (there are many around here, just test them and ship one). MaxAuthTries option could help with that. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Monday, 12 January 2015 8:32 PM, Paul Wouters wrote: do you use PrzemekKlosowski as your username on your fedora? I doubt it. It is more likely to be przemek, klosowski or pklosowski. In fact, often this is revealed in mail headers (eg sendmail invoked by user paul). More often, people will have 2 to 4 character usernames. So this information is far from secret, and easilly guessable. Agreed Paul, yet it does not mean cracking them would be as easy as slicing knife through butter. That too for every awkward joe trying their hands at it. It sounds like all one has to do is just guess the username, and it's game over. It is _not_! There is user's password, and root account's password. Not every non-root user has sudo(1) access. Besides when they use browser based mail clients, such information is less likely to be disclosed. As said before, few might be able to crack it, but others would _fail_ at it. And that failure is our net gain. Secondly, this restriction would encourage people to use non-root user accounts and help spread awareness about having strong passwords. Thirdly, as said in another thread, if we resort to using keys based authentication for 'root' account, it would lead to people using same mechanism for other accounts too. Overall in the long term, today's small change will have better cumulative returns. Compared to the dictionary this does in fact not make the problem any harder at all. However, you have made legitimate automated root logins much harder now, like me calling rsync as root for backups, which are not easilly done wrapped in sudo :P I wonder why rsync needs root account? If it's not easily done wrapped in sudo, why is brute forcing unknown username, its password and then root account relatively easier? (rhetorical questions, don't answer) Point is, if one must have to have only 'root' account in their set-up, they can always enable remote 'root' login by setting PermitRootLogin=yes. Just like how people flush firewall rules. There are various ways of doing that. Let's try to figure out how we could facilitate that with more convenience, rather than looping over same arguments about how the feature improves security or not. For malicious logins, once root access is obtained via password-less sudo, the evidence is removed from the logs. What..automatically? Or the assumption is that the attacker is the smartest soul on earth?? --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote: Not just virtualized deployments, but also in remote installs on bare metal. Okay and the '%post' install section trick won't help there? IIUC, it'd depend on which tool/application is used to do such remote installations and if they provide means to customise/tweak the final install. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Monday, 12 January 2015 11:27 PM, Mike Pinkerton wrote: Sure, if the tool provides the ability to tweak the install to enable password-based root login, then one can log in after installation, upload keys, configure sshd, etc. The question is whether the tool that is available has that ability. Over the years, I have attempted many of the remote installation methods described in the Fedora Installation Guide. Not all of them work when you don't control the remote network. Right, I understand. We'll still have time till F22 release to sort out these issues in tools. As said in the previous mail, if we agree on PermitRootLogin=without-password as the _default_ sshd(8) configuration, then next step would be to communicate the affected tools and workflow maintainers to make required changes to account for the sshd(8) configuration change. --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Saturday, 10 January 2015 1:34 AM, Mike Pinkerton wrote: Even if you want to do key-based authentication rather than password, you still need to use password initially to get the key onto the remote box. True! --- Regards -Prasad http://feedmug.com -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hello, I'm writing a common reply for consolidation and brevity. I'll try to cover all the concerns raised so far. - Idea behind this feature is to keep malicious users from gaining 'root' access to remote systems. Restricting remote root login increases the difficulty level in that, which could thwart significant chunk of attacks. Guessing non-root user name is doable, but still involves the complexity/work involved in doing that, which is _not same_ for all malicious users. Few might be able to crack it, while others would _fail_ at it. - The 'method' used to restrict remote root access is negotiable. Ie. disable it completely by setting PermitRootLogin=no OR disable remote root login via password by setting PermitRootLogin=without-password. Either one would serve the purpose, but also have implications on other workflows. - Major concern so far is how this feature could break existing workflows. That is genuine and can be addressed adequately. As said earlier in other threads, intention is certainly _not_ to trouble users, but raise the security bar of Fedora systems a notch higher. - Second tune is that the feature does not add any security. That is like saying having a security guard at the entrance adds no value, because atrocities still continue to happen around us. IMO, this feature certainly adds more value to Fedora than its perceived short term cost. Major use-cases discussed so far, across multiple threads are: 1. Local installations: wherein a user can navigate through the installation process as prompted by the Anaconda installer. The system being installed could be local or remote. The variant being installed could be server or workstation. 2. Automated installation: wherein a user can not navigate through the installation steps. The variant could be sever or workstation. 3. Cloud installations: wherein cloud images are built via automation tools with predefined configurations. Mostly these don't have(or need) non-root user account. Towards a better solution: PermitRootLogin=no * If we disable remote 'root' access, non-root user access becomes imperative. - Anaconda cloud_init tools already facilitate creation of non-root user accounts. - Creation of one non-root account could be made mandatory. - Omission of non-root account creation could show discretionary warning. - Omission of such user account creation could conditionally enable remote root access. PermitRootLogin=without-password * If we restrict remote 'root' access, exporting of ssh keys becomes imperative. - Cloud_init tool seems to have facilities for that. - Anaconda installer's state on this is not known yet. - Such systems would still need non-root user access. * Remote root access can be enabled in the '%post' install section of the kick-start file. - https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html Either approach entails some modifications to the current workflows. Though it seems PermitRootLogin=no could do with lesser than 'without-password' option. As said in the feature page, ...There is another option of disabling root login via password and require usage of cryptographic keys for the same. But that could be a next step in future. Please see: - https://www.piratepad.ca/p/ssh-remoterootloigin I have collated the above details on this pad. Please feel free to edit it as required. Your comments/suggestions are most welcome. Once again, intention is _not_ to trouble users, but to ensure their safety by default. Thank you. ---Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Wednesday, 24 December 2014 3:07 PM, Andrew Haley wrote: At some loss of usability. To often we hear This is better for security, therefore we should do it without considering the usability trade-off. It'll help if you could define this some loss of usability. If it is about remotely installed VM images, it's also discussed here - https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Wednesday, 24 December 2014 11:01 PM, Mike Pinkerton wrote: Remotely installed on bare metal. I see. Is there a provision that you could edit the kick-start file? Or supply parameters to it?? If so, it could be possible to enable remote root login post install. If not, let's see how we could address that. Which tool is it? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Co-maintainer required for 'dcmtk' Fedora package
Hello, Please see: - https://bugzilla.redhat.com/show_bug.cgi?id=1104041#c6 - https://admin.fedoraproject.org/pkgdb/package/dcmtk/ Mr Mario, the current maintainer is looking for a co-maintainer for the 'dcmtk' Fedora package. If you are interested, please apply for the co-maintainer commit access via the package db(pkgdb) link above. The latest 'dcmtk' snapshot build needs to be pushed to Fedora repositories to fix the bug above security issue. Thank you. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
Hello Tomas, On Thursday, 27 November 2014 3:05 PM, Tomas Mraz wrote: - Original Message - On Wed, Nov 26, 2014 at 11:48 AM, Scott Schmit wrote: Look, this is a basic system configuration. It's not Cripple Mr. Onion. Pick *one* setting, and let people know from that whether they'll need to manipulate their local environments for their particular subtle needs. Exactly! The more I think about this Change the more I am having an opinion that we should reject it altogether. In fact this change does not really bring any real security improvement because for the Workstation the sshd is already disabled completely by default and for the other products the people who are installing them can be expected to know what they are doing. That's not a prudent expectation. Also disabling root access does not improve security against targeted attacks because in such cases the user name can be quite easily inferred. So basically this feature is just a 'marketing' improvement and not worth the hassle. I disagree. Just because it is easy to infer non-root user names does not mean we tell people it is 'root'. Secondly, it might be easy for you to infer such names, not for everyone. The increased difficulty level that is added by not allowing remote root login could help to thwart lot of real automated attacks.[1] Thirdly, it need not have to be entirely about security, it's also about picking the right default configuration. Same as disabling sshd(8) in Workstation by default. As Scott wrote above ...Pick *one* setting, and let people know from that... This feature, like any other, requires users to tweak their current practices to suite the new defaults. That is no reason to not do it; Because in the longer run it is only beneficial. [1] https://lists.fedoraproject.org/pipermail/security/2014-November/002031.html --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Thursday, 27 November 2014 4:49 PM, Reindl Harald wrote: so why not consider disable sshd at all and make a checkbox in Anaconda ssh support yes/no because after somebody says yes it's his clearly decision and he is responsible to secure it with key-only auth Sure these are options, which need to be evaluated against their pros and cons. For the 'Disable remote root login' option, this evaluation has been more positive than negative. Cases wherein it is negative, is mostly due to the tweaking that users would have to incorporate in their workflow, ex. explicitly enable remote root login after creating a new VM. This is easily doable because these users are fairly experienced ones. Idea is not to punish them for it, but to depend on their expertise rather than to expect that unknown users would/should know how to safe guard their systems. Overall this feature adds more value to Fedora, than its perceived short term cost. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tuesday, 25 November 2014 8:53 PM, Kevin Fenzi wrote: On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce wrote: We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible. This has been the reason this hasn't been changed the last few times someone proposed to change it. I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage. If you want to remove root access that should be conditionally done at firstboot only if a user account was created. This seems a more reasonable place to look to change this, I agree. True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tuesday, 25 November 2014 9:07 PM, Simo Sorce wrote: My machines get joined to an IPA domain as soon as they are finished installing, I do *not* want a local user, it would be a liability. Well, I think this is more specific case for which remote 'root' login could be enabled by user. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
Hello Matthew, On Tuesday, 25 November 2014 9:21 PM, Matthew Miller wrote: Keep in mind that in cloud, cloud-init does the same thing (instead of firstboot). Ah I see, cool! --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
Hi, On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's, so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple, True, it is complex. Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5). (Just a thought) --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Sunday, 23 November 2014 1:59 AM, Rahul Sundaram wrote: I would suggesting going through the feature process. Although the config file change itself is trivial, there are multiple components that require coordination with several teams (Anaconda, Fedora Security team, openSSH, GNOME etc), testing and documentation. Having FESCo review a proposal is useful as well. Right, makes sense. I'll do that. I'm from Fedora Security Team above; that is where this topic/discussion came up and lead to this thread. Thank you. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Monday, 24 November 2014 2:59 PM, P J P wrote: On Sunday, 23 November 2014 1:59 AM, Rahul Sundaram wrote: I would suggesting going through the feature process... Having FESCo review a proposal is useful as well. Right, makes sense. I'll do that. Please see - https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote: On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: The latter. We have to install authorized_keys inside the VM anyway, so we can touch sshd_config, too. Virt-builder has a new '--ssh-inject' feature (in F22 only). $ virt-builder fedora-20 --ssh-inject root would inject your current ssh key into the root account of the new VM. There are other variations, including ways to create a non-root user account, see: http://libguestfs.org/virt-builder.1.html Excellent! :) So far the consensus seem that it is okay to reverse the current default and set PermitRootLogin=no. I'll talk to the upstream maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba). Thank you. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Saturday, 22 November 2014 4:29 PM, Felix Schwarz wrote I'm ok with no root login assuming that one can ssh into the machine (and become root somehow) after an install (this is along the lines of what Harald Reindl mentioned yesterday). Yes, true. One would definitely need a non-user access to the system. Maybe by compulsory/default non-root user account creation. Seems that this means there must be some other user account on the system (or just use PermitRootLogin without-password which is my favorite option right now anyway). I guess you'll take care of that? Yes, we'll ensure that noone is locked out of their systems after a fresh install or upgrade. Thank you. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Saturday, 22 November 2014 9:28 PM, Rahul Sundaram wrote: This seems pretty tricky to ensure. Anaconda doesn't enforce an additional user because that could be done via the initial setup or gnome initial setup. IIRC, the interactions between them were pretty non obvious already. Yes, true. We need to talk to them about it yet; still in the process. And that's why I was wondering if it needs to be a fully fledged feature? or just talking to upstream maintainers would do it? --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Friday, 21 November 2014 1:24 PM, Florian Weimer wrote: On 11/21/2014 08:34 AM, Jan Kratochvil wrote: Almost all of my Fedora installations are test VMs where any security is irrelevant. Okay. But does enabling root login offer any significant benefit in that? IOW, if it's disabled by default, would it cause any significant inconvenience/troubles?? If not, it better be disabled by default. I think it's a valid use case, but rather poorly supported at the moment. For example, there should be completely seemless SSH login from virt-manager for user-manageable virtual machines (both as root and the user). My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on. You mean off? Or that we disable it by default and enable it while setting up a new VM? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Abotu setting 'PermitRootLogin=no' in sshd_config
Hello, Sshd(8) daemon by default allows remote users to login as root. 1. Is that really necessary? 2. Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that. Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature? --- Regards -Prasad http://feedmug.com -- 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 Activity Day - 1st Nov 2014 - theme security
Hello all, See - https://fedoraproject.org/wiki/FAD_Pune_Security_1 Date: Say, 1st Nov 2014 Venue: Red Hat Inc. Tower-10, Magarpatta City, Near Hadapsar, Pune, India. On 1st Nov 2014, we plan to host a Fedora Activity Day(FAD) geared towards triaging security bugs in Fedora. The day would start with a brief introduction to Fedora Security and progress towards collective bug triaging. If you are in Pune or plan to be here on 1st Nov, please feel free to drop in and join the action. :) Please note:- we have limited capacity(=~25) to accommodate participants. ...see you there! :) --- Regards -Prasad http://feedmug.com -- 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: Unofficial Poll: Flock 2015 (North America) Bids
Hello, On Sunday, 21 September 2014 9:18 PM, Stephen Gallagher wrote: * Salt Lake City, Utah, USA[1] * Colorado Springs, Colorado, USA[2] * Rochester, New York, USA[3] * Cape Cod, Massachusetts, USA[4] - -5: I would not want to attend Flock if it was held in this location. 0: This location has no effect on my decision to go to Flock. 5: I would go to Flock just for the excuse to visit this location. Isn't there a better way to conduct this survey, maybe 'pollcode.com' or something like that? Anyway fwiw Cape Cod, Massachusetts, USA = +5 Rochester, New York, USA = 0 Colorado Springs, Colorado, USA = 0 Salt Lake City, Utah, USA = 0 Thank you. --- Regards -Prasad http://feedmug.com -- 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: Systemd boot issue
Hello Chris, On Wednesday, 10 September 2014 9:15 PM, Chris Murphy wrote: Well I have no idea what's on the screen at the time of the hang. Maybe a cell phone photo would be useful. Or maybe you should use the debug kernel which was one of Paul Wouters suggestions. Or you could go out on a limb and see if the problem is happening with 3.17rc4 non-debug which is http://koji.fedoraproject.org/koji/buildinfo?buildID=575871 There are lots of kernels. Unless you really want to do kernel troubleshooting, you might just pick a kernel that works. Yes, I've resorted to 3.15 for now. Will look at 3.16 again later, got a sosreport yesterday by trying 3.16 on a F20 VM. I'll post an update asap. Thank you! --- Regards -Prasad http://feedmug.com -- 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: Systemd boot issue
Hi, On Wednesday, 10 September 2014 12:28 PM, poma wrote: dr. acut? Can't say for sure. I added rdshell rd.debug parameters to the boot command line, again it throws a long list of debug messages from - /lib/dracut-lib.sh@xxx. Messages are about trying to setup /etc/sysconfig/network-scripts and dhclient(8) configurations it seems. It has snippets like for f in '/$_dir/*.sh' '[' -e //lib/dracut/hooks/cleanup/10-kill-dhclient.sh ']' . //lib/dracut/hooks/cleanup/10-kill-dhclient.sh for f in '/tmp/dhclient.*.pid' '[' -e '/tmp/dhclient.*.pid ' ']' continue ... /bin/dracut-pre-pivot@29(): exit 0 systemd-journald[2842]: Received SIGTERM systemd-journal (2842) used greatest stack depth: 12920 bytes left Note:- Systemd(1)/dracut(8) debug logs are serious information overload. They zoom past through the screen inundating it with thousands of lines, you can not even see them all. What's the point? Anyway...any clue? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Systemd boot issue
Hello, I've been trying to boot into kernel-3.16.0 on a F19 machine. But it just stops after saying ... [OK] Reached target Initrd Default target System is not hung, but there is no activity/progress either. I did search about it, some say it's because of SELinux. But other kernels do boot with SELINUX=enforcing on my machine, so I'm not sure. I asked on IRC channels, but no fix in sight yet. Is it a familiar issue to anyone? Is there a way to debug what Systemd is doing after printing above message?? Thank you. --- Regards -Prasad http://feedmug.com -- 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: Systemd boot issue
Hello Daniel, Chris, Thank you so much for sharing the links and the notes, much appreciate it. On Wednesday, 10 September 2014 12:23 AM, Daniel J Walsh wrote: Did you try to boot with enforcing=0? To see if it is an SELinux issue? Yes I tried with enforcing=0, it does not seem to help. It still halts at the same spot. Upon removing 'rhgb quiet' parameters from the boot line, it shows systemd-journla[12321]: received SIGTERM And the screen before that is assorted with messages like: /systemd-fstab-?[23213]: used greatest stack depth: 12332 ... ... systemd-udevd[14322]: used greatest stack depth: 12920 ... ...not sure what the real glitch is. I'll try more...let's see. --- Regards -Prasad http://feedmug.com -- 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: Systemd boot issue
Hi, After removing 'rhgb quiet' and adding 'systemd.log_level=debug systemd.log_target=console' it generates a huge pile of debug messages at halts at - Switching root. I tried booting the _same_ 3.16.0 kernel on another F20 machine, it stops at the same spot. :( --- Regards -Prasad http://feedmug.com -- 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: what is the latest kernel in FC20?
On Sunday, 7 September 2014 1:34 PM, Pál, László wrote: Yes, it was yum but I have the same for dnf. The error message is installed package is not available (both for kernel and headers). How much time needed to able to install a package after pushed to stable? Well, once pushed to stable, they are readily available without much of a delay. --- Regards -Prasad http://feedmug.com -- 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: what is the latest kernel in FC20?
Hello Pal, On Sunday, 7 September 2014 12:57 PM, Pál, László wrote: A few weeks ago I had to upgrade my kernel due to some nvidia related issue. Installed package kernel-headers-3.15.10-200.fc20.x86_64 (from updates) not available. Error: Nothing to do What was the yum command used here? Trying to install a package that is already installed shows message like: -- Package kernel-headers-3.14.17-100.fc19.x86_64 already installed and latest version Nothing to do -- I've checked the package list and I can see some similar package with patch level 201 but yum cannot install it. What's wrong here? - https://admin.fedoraproject.org/updates/FEDORA-2014-9959/kernel-3.15.10-201.fc20?_csrf_token=7b0d6db0a1ef17eb70f1b2197888f6e4619b5c6c It was pushed to stable on 30th Aug, not long before. --- Regards -Prasad http://feedmug.com -- 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: F21 System Wide Change: Default Local DNS Resolver
Hello, On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote: So what exactly happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf? After upgrade, the default DNS resolver should listen on 127.0.0.1:53. And the entry will be added to '/etc/resolv.conf' by NetworkManager. The old contents of the file should be passed on to the local resolver as transitory name servers. The actual workflow is currently being worked upon. Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system? We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53. Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined? The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender. --- Regards -Prasad http://feedmug.com -- 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: F21 System Wide Change: Default Local DNS Resolver
On Tuesday, 29 April 2014 7:56 PM, Matthew Miller wrote: Can the proposal owners clarify for me how this is intended to impact the cloud products? Cloud products is somewhat of a hazy area(at-least for me). It's unclear how things operate there. Any information about how we could/should address it well is required and most welcome. Please see - https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html Thank you. --- Regards -Prasad http://feedmug.com -- 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: F21 System Wide Change: Default Local DNS Resolver
Hi, On Tuesday, 29 April 2014 8:59 PM, Dan Williams d...@redhat.com wrote: If NetworkManager is being used, users already don't touch resolv.conf, they edit /etc/sysconfig/network-scripts/ifcfg-* files and use DNS1/DNS2/DNS3 and SEARCHES to set DNS information. Yes, true! If NetworkManager is not being used, then the proposal needs to address what config file users *do* edit to ensure that the upstream DNS servers are pushed to the caching nameserver. If NetworkManager is not used, dnssec-trigger seamlessly handles lot of its responsibilities. I'll update the proposal page with information about it. --- Regards -Prasad http://feedmug.com -- 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: F21 System Wide Change: Default Local DNS Resolver
On Tuesday, 29 April 2014 9:29 PM, Paul Wouters p...@nohats.ca wrote: Note that FreeBSD also picked unbound recently for the exact same task. True! - http://www.freebsdnews.net/2013/09/20/freebsd-10s-new-technologies-and-features/ --- Regards -Prasad http://feedmug.com -- 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: F21 System Wide Change: Default Local DNS Resolver
Hi, On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski l...@mit.edu wrote: but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Ah, interesting! Thank you so much for sharing these details. OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container. I think this is a better option than having a different device address like 127.0.0.53. Forwarding traffic from inside namespace to a loop-back device on the host is analogous to a guest(VM) forwarding traffic to its host via bridge interface. Thank you. --- Regards -Prasad http://feedmug.com -- 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: F21 System Wide Change: Default Local DNS Resolver
On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote: On my home LAN, I run my own DNSSEC-enabled server using F20 bind 9. This local server also is my DHCP and Samba server. As usual, dynamic clients receive the LAN local domain ID and DNS server ID automatically. How does this proposed change affect my clients, or especially my server (which uses NetworkManager (not Network), and a static IP address? This should work just fine. If you upgrade your F20 machine to say F22, it would have the default resolver running on 127.0.0.1:53 with its entry in '/etc/resolv.conf'. One change you would need to do is to make it listen on 0.0.0.0:53 or the on static IP address of your server. Your clients won't know that they are talking to a different DNS resolver. If your clients are upgraded to F22, NetworkManager there would make the local resolver talk to the one on your server, because it'll receive that name server configuration via DHCP. As nice as unbound may be, documentation and configuration files related to this change should not assume it is the only DNS server for Fedora. Nope, we don't assume that. In fact it's been discussed earlier here - https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html --- Regards -Prasad http://feedmug.com -- 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: default local DNS failover solution needed, nscd?
Hi, (sorry for the delayed response, I was away past few days) 2014-04-26 0:51 GMT+02:00 Chuck Anderson wrote: Main goal is to have local DNSSEC-validating resolver. I, as the OP, did not intend that as the goal, although I have no problem with that as a different goal. My intent was to fix the atrocious failover behavior of the glibc resolver. Agreed. There are several reasons to have a local DNS resolvers. Nonetheless, one solution may not address all use cases. For that reason, one of the requisites gathered from the earlier long thread is + Choice between different DNS resolvers - unbound, bind, dnsmasq, dnslookupd etc. etc. - you would want to have plugins for those in NetworkManager - Right. Please see - https://www.piratepad.ca/p/dnssec-requisites-configurations As Miloslav rightly said, supporting each new DNS resolver would entail resolver specific integration work and relevant upstream development work. We plan to do our _best_ to address maximum use cases and provide due guidance for the others. But for that, it is essential to gather first hand data and list down all the DNS resolver use cases across desktops/servers/workstations/thin clients/data centres/cloud/containers etc. etc. Anything and everything that uses DNS resolver, we need to know about it. Having such data would _greatly_ help to device a robust solution. Please help us by spreading the word about it, so that we have more more real life data on that ether pad. That way we can estimate the amount of work to be done and invite contributors to take-up individual tasks. More hands together can easily make huge difference. On Saturday, 26 April 2014 4:29 AM, Miloslav Trmač wrote: Right now I'd actually guess that it's more likely to have a DNSSEC-validating resolver soon, than the simple caching daemon you propose. Specific people are already dedicated to working on the former, and the principal elements of the solution already exist; what is left is (a large amount of) integration work. And that will also inherently handle the caching/failover case for free. Very true! --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server: test it right now and report bugs
Hi, On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote: We need real data. Please see - https://www.piratepad.ca/p/dnssec-requisites-configurations I've collected the major functionalities people wish to have with a default DNS resolver along with couple of 'unbound' configurations that I tried. It'll greatly help if others could also list their configuration details on the same page. Thank you. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server: test it right now and report bugs
Hello Petr, On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote: Instructions for testing on Fedora 20+ are available on: https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test Please, run dnssec-trigger and let exclamations like It can't possibly work! apart. Send constructive bug reports instead. We need real data. Excellent! Thank you so much for doing this Petr. I was going to do the same. Summarise the discussion so far, list down the problem areas and invite users to report their problems. Having real first hand data and bug reports would be extremely effective in developing the NM plugins and integration with NM. I'll try both the configuration on my machine. Thank you! :) --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New configurations in /etc/resolv.conf
Hello, Please see: - http://www.ietf.org/mail-archive/web/dane/current/msg06469.html - https://www.ietf.org/mail-archive/web/dane/current/msg06658.html These two threads are about handling of Authenticated Data(AD) bit by the stub resolvers. There two proposed solutions for this problem: 1) To install a 'trusted' local resolver running on 127.0.0.1:53. A system wide change request has been filed for this. - https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver 2) To strip the AD bit in stub resolvers by default. This requires new configuration parameter(s) to be defined in '/etc/resolv.conf'. This is required because, till the time 'trusted' local resolver becomes a norm, applications need some way to know whether the listed name servers in '/etc/resolv.conf' are trustworthy or not. The discussion is open for ways to convey 'trustworthyness' of the listed name servers to the requesting applications and ways to enable/disable AD bit stripping in the stub resolver. Your inputs/comments about syntax semantics of the new configurations in '/etc/resolv.conf' are most welcome. Thank you. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 11:11 AM, William Brown wrote: Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the unreliable ISP. I then go to work and suddenly things don't work. Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP. What, no! that was the case for having local cache and not forwarding queries to the ISP's name servers at all. Because those are not reliable. See my previous email, about flushing the cache on network change. Yes I saw. About automatic cache clearance etc. I agree. Those are features to be requested from the DNS software or maybe NM. I've been using 'dnscache' without any trouble whatsoever. See - http://pjp.dgplug.org/ndjbdns/ --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 12:41 PM, William Brown wrote: PS: The unreliable ISP I perceive as: 1) They often return no query within an acceptable time period 2) They return invalid or incorrect zone data 3) They mess with TTLs or other zone data Right. Consider, I get home, and open my laptop. Cache is cleared, and I'm now populating that cache with the contents from the ISP. No, why contents from ISP? Local resolver will populate cache from root servers, no? But if you weren't to clear the cache, I could be at home caching bad records, then when I go to work they persist. This is a glitch that when you are at home the cache still has office domain addresses cached, to which you can not connect, because you aren't connected to the office network. Do I understand it right? IMO, that's not bad cache. You cannot have both. I would rather that cache is flushed on interface change as it prevents so many more issues than making that cache last across potential network boundaries. Sure, no contention there. IMO, that could be a feature for NM, to clear local cache on interface change. Because NM is suitably placed to do that. At the end of the day, I cannot stress enough, if you have an ISP with bad DNS caching or that is unreliable, you need to fault your ISP, IMO, local resolver can help here. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 4:55 PM, William Brown wrote: This isn't how DNS works . You populate your cache from the ISP, who queries above them and so on up to the root server. http://technet.microsoft.com/en-us/library/cc961401.aspx Hmmn. There are two ways a local resolver can be configured. One is it contacts root servers and builds its cache from their responses. That's recursive name resolution. And second is it acts like a stub resolver and forwards client queries to another recursive resolver. N-DJBDNS supports both these options. Maybe you could install it and see for yourself. try - # yum install ndjbdns I should clarify. I cache the record foo.work.com from the office, and it resolves differently externally. When I go home, it no longer resolves to the external IP as I'm using the internally acquired record from cache. No. Your foo.work.com address does not resolve to a public internet address, but resolves to an internal company specific address. And when you come home, your domain foo.work.com still resolves to the _same_ internal address, but you are unable to connect to it because you are outside of the office network. Try connecting over VPN connection from home. A local cache will help you with 1 sometimes provided you get the first record back once. It won't prevent the second or third as you will just cache the incorrect data instead (Provided you clear cache on network change, this isn't a problem ... it just means you hold onto bad data for that session for longer, which creates other issues.) I personally am actually against DNS cache on systems as it tends to create more problems than it solves. Maybe you could try N-DJBDNS - # yum install ndjbdns --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
Hello, On Thursday, 10 April 2014 11:39 PM, P J P wrote: I plan to file a feature/change request for this one. I got caught up with other work this past week so could not do it. Will start with it right away. Please see - https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver It's a System Wide Change Proposal request up for review. I have set the target release as F22, because the proposal deadline for F21 was 08 Apr 2014 [1]. Besides, this change would require significant work on the related packages like NetworkManager etc. So F22 seems safer. In case if you spot any discrepancies or have additional inputs or links to relevant documents etc. please feel free to update the wiki page or let me know and I'll add it there. -- [1] https://fedoraproject.org/wiki/Releases/21/Schedule Thank you. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 12:28 AM, Bruno Wolff III wrote: I think there should be something explicitly about how this is going to work with captive portals that lie about dns in order to get people's web browsers to go to their sign in page. Sorry, I did not get the question. Could you please explain it a bit? Thank you. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 12:40 AM, Bruno Wolff III wrote: It looks like your proposal is going to break things for people using some wifi hotspots. Why, how? --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
Hello Dan, On Saturday, 12 April 2014 12:51 AM, Dan Williams wrote: NM has had local caching nameserver capability built-in since Fedora 12 or something like that. Set 'dns=dnsmasq' in the [main] section of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in a local caching nameserver configuration and write 127.0.0.1 to resolv.conf. NM will update that dnsmasq instance whenever your network configuration chagnes to ensure that dnsmasq has the latest nameservers. It seems that 'unbound' is getting more love these days though, due to it's DNSSEC capabilities, and there is not yet a NetworkManager DNS plugin for unbound/dnssec-trigger. I know some people are working on that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show up in the near future. Note that hotspot detection is an important part of this, since hotspots will clearly break any kind of DNSSEC validation that happens, and that's something that's being worked out between dnssec-trigger and NetworkManager right now too. NM in F20+ already has a dns=none option that prevents NM from touching resolv.conf, but obviously if NM isn't touching it, the DNS information that NM gets from upstream or your local configuration needs to get to the local caching nameserver somehow. Which is what the existing NM DNS plugins are for, like the dnsmasq one. That's great. Thank you so much for sharing this information. I'll add it to the wiki page. About the wifi hotspots breakage, I'm still not in the clear. IIUC how they work is, all client traffic is blocked/redirected to a designated server till the time user authenticates/makes payment/accepts conditions etc. This blockage/redirection is probably done on the the gateway or some such entry/exit point, no? Thank you. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
Hi, On Saturday, 12 April 2014 12:56 AM, Dan Williams wrote: We want to make sure that any local caching nameserver that we do use doesn't rely exclusively on file-based configuration, or if it does, it's able to re-read that configuration file using SIGHUP or some seamless reload functionality. It *must* also be able to load new configuration without dropping in-process DNS queries on the floor, otherwise users will experience hung DNS a non-trivial amount of the time. The better way is to add/remove zones + servers from dnsmasq over D-Bus, which NM does not yet do since the patches are not yet upstream, or to use some other socket-based protocol like unbound does with dnssec-trigger. Sure, makes sense. This workflow bits need to be worked out still. File based configuration is just an example. Important is that dynamic name servers augment the local name server rather than replace it. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 1:35 AM, Miloslav Trmač m...@volny.cz wrote: The goal is to have DNSSEC validation in a system-wide, dedicated code, trusted for that purpose; i.e. unbound does DNSSEC validation for every application, with a centralized configuration and cache, so no application needs or should do this on its own; it can simply consult the AD bit in the reply. ... Not necessarily, and probably not. ... Thanks so much for the precise responses Miloslav. But, am I the only one to not see Dan's earlier mail? Or was it a different thread?? Thank you. --- Regards - Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote: It's rude to bypass the global DNS caching infrastructure. That would significantly load people's DNS servers with more queries. There is no reason not to try and use ISP's DNS caches. You mean let local resolver forward queries to the ISP's name servers? That is same as using ISP's name servers in '/etc/resolv.conf'. I wouldn't prefer that without DNSSEC. dnscache is very obsolete software. - http://pjp.dgplug.org/ndjbdns/ There is new version of it. It does not support DNSSEC, but is alive and well maintained. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
Hello Kevin, Paul On Saturday, 12 April 2014 2:16 AM, Kevin Fenzi wrote: I've been running this solution on fedora for about five years now. It works reasonably well, and anyone who is on this list surely has could try it out. Because of lack of NM integration I would not call it enduser ready yet. Me too. :) Does it work out of the box? I mean just $ yum install unbound and it works, or there are some steps involved to configure it neatly. For ex. internal domains etc. If so, it'll be extremely helpful to document these steps on the change wiki. Or if there is already a document about it, please link to the same. Or let me know and I'll do it. Thank you. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 3:55 AM, Chuck Anderson wrote: I think there needs to be more emphasis on the /other/ benefit, the whole reason I brought this up this time: Sure; I tried to cover it in the detailed description as === ...Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) === Also, this thread is linked there at [3]. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 7:38 AM, Simo Sorce wrote: Not true, in many networks you want it, for example in corporate networks. You really want to be able to resolve the local resources and they are only resolvable if you consult the local DNS as provided to you by DHCP. True. The local resolver can be configured to resolve internal domains by pointing it to the dynamic name servers. Also one can set 'DNS1=127.0.0.1' in /etc/sysconfig script, that way dynamic name servers are listed as DNS2, DNS3 etc. For this very reason the dynamic name server entries need to go as ..transitory name servers to be used by the trusted local resolver. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
On Saturday, 12 April 2014 10:33 AM, P J P wrote: On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote: It's rude to bypass the global DNS caching infrastructure. That would significantly load people's DNS servers with more queries. There is no reason not to try and use ISP's DNS caches. There is also the case that Chuck mentioned about ISP's name servers being unreliable. --- Regards -Prasad http://feedmug.com -- 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: default local DNS caching name server
Hello Chuck, Thank you so much for brining this up. On Thursday, 10 April 2014 8:12 PM, Chuck Anderson wrote: I think this needs to be revisited. We need an independent, system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to solve this fundamental design problem with how name resolution works on a Linux system. Totally agree. In fact, recently there have been multiple instances of discussions wherein this exact same topic was discussed and unanimously everyone agrees that for various reasons having a default local DNS resolver running at 127.0.0.1:53 is the best solution. And going forward it'll be even more beneficial. Paul pointed to one of these discussions in his reply. I plan to file a feature/change request for this one. I got caught up with other work this past week so could not do it. Will start with it right away. Thank you! --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Tuesday, 15 October 2013 12:51 PM, Jan Zelený jzel...@redhat.com wrote: Even though yum might handle the resolution a little better (and dnf probably will do that, feel free to check it), the ultimate culprit here is a very poor packaging and both dnf and yum have only a limited set of options what to do in such cases. Yeah, true. --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Monday, 14 October 2013 8:05 PM, Eric H. Christensen spa...@fedoraproject.org wrote: I believe he is assuming that xchat has a direct relationship with bluez which, I'm guessing here as I haven't checked, probably isn't the case. Because bluez affects something that xchat depends on xchat is getting thrown into the pile of things that will break without bluez. Dependencies aren't always 1:1... Yes, I understand that Xchat is not directly dependent on bluez; It is being a victim of associative dependency, something like bluez = gnome-bluetooth(libgnome-bluetooth-applet.so.0) = gnome-shell = libnotify.so.4 = xchat My original question was if this is due to a packaging error or if yum's dependency resolving algorithm is at fault. Because with remove_leaf_only=1, if you try to remove individual packages, # yum remove bluez, # yum remove gnome-bluetooth # yum remove pulseaudio-module-bluetooth None of them work. But if you try to remove all 3 together # yum remove gnome-bluetooh bluez pulseaudio-module-bluetooth Yum prompts you to remove bluez - https://lists.fedoraproject.org/pipermail/devel/2013-October/190101.html --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Yum dependency resolving remove_leaf_only
Hello It is an often experience that I try to remove a package(ex: bluez, kernel, gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical packages, which has no connection(ex. kernel = Xchat OR bluez = gedit etc.) with the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf, which should help remove only the leaf node packages and nothing else. So I set it. But after setting remove_leaf_only=1, I can remove _none_ of the packages because of the dependency issues. Even when I try to remove _all_ of the dependency packages I'm barely allowed to remove but a single package. (see below) I wonder why is this so? Is this an error in the way packages are built OR isit yum(8)'s dependency resolving algorithm that is broken? I've also seen instances wherein yum installs _new_ package during yum update. All this does not seem good at all. Many of the folks, with whom I've argued for Fedora, cite yum(8) to be the foremost reason for not liking Fedora. Does the new DNF(https://fedoraproject.org/wiki/Features/DNF) plans to address these issues? Till then is there a known remedy for yum(8)'s illness?? === [~ @ 21:44]# yum remove bluez Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package bluez.x86_64 0:4.101-9.fc19 will be erased --- Keeping package: bluez-4.101-9.fc19.x86_64 due to pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 -- Finished Dependency Resolution [~ @ 21:45]# [~ @ 21:46]# yum remove pulseaudio-module-bluetooth Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased --- Keeping package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 due to 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 -- Finished Dependency Resolution [~ @ 21:46]# [~ @ 21:46]# yum remove gnome-bluetooth Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased --- Keeping package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 due to bluez-4.101-9.fc19.x86_64 -- Finished Dependency Resolution [~ @ 21:46]# [~ @ 21:46]# yum remove gnome-bluetooth bluez pulseaudio-module-bluetooth Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package bluez.x86_64 0:4.101-9.fc19 will be erased --- Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased --- Keeping package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 due to gnome-shell-3.8.4-2.fc19.x86_64 --- Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased --- Keeping package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 due to 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 -- Finished Dependency Resolution Dependencies Resolved === Package Arch Version Repository Size === Removing: bluez x86_64 4.101-9.fc19 @updates 1.9 M Transaction Summary === Remove 1 Package Installed size: 1.9 M Is this ok [y/N]: N === Thank you. --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 10:19 PM, Reindl Harald h.rei...@thelounge.net wrote: that's why i get that mad if packagers careless add new deps because they enable whatever function in a package instead split the new ones in additional subpackages I see. If it is a packaging error, how does DNF plan to address it? on a tiny setup one small added dependency often pulls *a lot* of other dependencies the user did not use and install for good reasons like keep the footprint small and make dist-upgrades fast True, couldn't agree more. I too strive to install the bare minimum required packages, but invariably I lose after the first $ yum update post system install. :( --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 10:31 PM, Samuel Sieb sam...@sieb.net wrote: If there's a bug, then this is it. You should not be able to remove bluez because there are dependencies on it. Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes only, that is why it allows removing bluez. --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 10:43 PM, Reindl Harald h.rei...@thelounge.net wrote: *why* should it be addressed in yum or DNF? if a package pulls un-needed dependencies the package has to be fixed and *not* worked around it - period Yes, agreed. But that might probably involve fixing the package review process wherein a new package is introduced. Once the package is approved and enters repositories, subsequent updates could introduce new dependencies. These updates do not go through any manual review process. Spotting dependency errors by inspecting the .spec file seems like quite a task, at least it's difficult to spot without manual inspection. One solution could be for Yum(8) or DNF to only list the dependency packages to caution a user that if you remove the said package, these many packages would be affected. But prompt him to remove only the selected package and not 100 others along with it. Ie. If I ask to remove package bluez, do let me know that 100 other packages might not work, but prompt me to remove only and only package bluez and not the 100 other affected packages. This would significantly simplify user's decision making and thus improve user experience too. --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 11:23 PM, Reindl Harald h.rei...@thelounge.net wrote: if you want get a feeling in waht these ends type the follwoing as root after you prepeared a rescue-disc because not rpm, nor yum nor even sshd will work any longer and you need to copy the package files by hand to their location - have fun, tried it in a VM rpm -e --nodeps nss-softokn-freebl Well, with --nodeps you already allow rpm to remove a package without knowing which other packages it might affect. I tried it with yum(8) instead, after resolving a huge list of dependencies possibly involving _every_ installed package it could find, including libc.so.6 systemd, finally yum refused to remove it. That is smart. === [~ @ 23:30]# yum remove nss-softokn-freebl ... -- Running transaction check --- Package foomatic-db.noarch 0:4.0-38.20130604.fc19 will be erased --- Package icc-profiles-basiccolor-printing2009.noarch 0:1.2.0-3.fc19 will be erased --- Package kernel-modules-extra.x86_64 0:3.11.3-201.fc19 will be erased -- Finished Dependency Resolution Error: Trying to remove systemd, which is protected Error: Trying to remove yum, which is protected === Yum(8) already has some intelligence built into it to protect a naive user from possible disasters. Considering that, it is okay to let user remove other packages at will. --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 12:04 AM, Reindl Harald h.rei...@thelounge.net wrote: and your list possible affected packages but allow me to remove ends *exactly* there No, it does not. If yum is protecting users from un-installing a package which could render the whole system unusable or unresponsive, what remains is not-so important packages, which pull in 100 other _unrelated_ packages to the list of packages to be removed. And invariably user is left with no choice but to type - 'N'; unable to remove a package. BTW: thank you for quoting out of context and no i am too lazy to search your Sorry, I quoted out of context? --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 12:50 AM, Reindl Harald h.rei...@thelounge.net wrote: there is no if and but if a package has a dependency than it has one - period Sure, it has dependency. That does not make it an _absolutely_ requirement to have a functional system. Because the dependency relationship could be broken. We already agreed on that, no? Ex. I try to remove package bluez, and yum prompts me to remove gnome-shell, gthumb, xchat and several other unrelated useful packages. Does that mean gnome-shell, xchat gthumb can not function without package bluez? No. It means dependency relationship is broken. That is why it is okay to let user remove package 'bluez'. If it breaks something, user can still re-install bluez without much hassle _if when_ he/she figures out that things aren't working as expected. Otherwise it's good riddance, one unwanted package less. === [~ @ 01:00]# yum remove bluez Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package bluez.x86_64 0:4.101-9.fc19 will be erased -- Processing Dependency: bluez = 4.34 for package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 -- Processing Dependency: bluez = 4.42 for package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 -- Running transaction check --- Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased -- Processing Dependency: gnome-bluetooth(x86-64) = 3.5.5 for package: gnome-shell-3.8.4-2.fc19.x86_64 -- Processing Dependency: libgnome-bluetooth-applet.so.0()(64bit) for package: gnome-shell-3.8.4-2.fc19.x86_64 --- Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased -- Running transaction check --- Package gnome-shell.x86_64 0:3.8.4-2.fc19 will be erased ... === I wonder why is gnome-bluetooth required by gnome-shell, it should be the other way round, no? there are no soft-depencencies and any hack allow you to remove a pakcage which is required by another one and ignore this requirement is pretty dumb Heh, and leaving users unable to remove unnecessary packages by prompting them to remove 100 unrelated useful packages is not dumb? --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III br...@wolff.to wrote: Your example of removing kernel is even more esoteric. Fedora wouldn't work at all without it. Well, kernel one works when there are multiple kernels installed. It happens when yum installs a new kernel update. Each kernel brings along its respective kernel-devel, kernel-header packages. --- Regards -Prasad http://feedmug.com -- 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: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 1:47 AM, Reindl Harald h.rei...@thelounge.net wrote: *bullshit* you have no clue what the result of a specific broken dependency would be nor have yum, dnf or even god Well, when no-one has a clue, assuming the worst is just _one_ way of doing things. says who? in case of bluez it maybe does not make troubles and the dependency should be bluez-libs and if a package links to /usr/lib64/libbluetooth.so.3 and yum would allow you to remove it the app would *crash* Heh..that is what broken dependency means. *yum and whatever package managmement* are *not* repsponsible for wrong dependencies and since there are no soft-dpendencies in RPM implemented the only thing which is broken is the package pull braindead cross-deps Yes, we already agreed on this. --- Regards -Prasad http://feedmug.com -- 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: About F19 Firewall
Hello Adam, - Original Message - From: Adam Williamson awill...@redhat.com Subject: Re: About F19 Firewall That's ironic: just yesterday - without having yet read this discussion - I used the firewalld on my laptop to lock down the 'public' zone to allow nothing at all (not mdns or ssh), make sure it was the default zone, then special-case the connection for my home wireless network to be in the 'home' zone. Took two minutes. I'd have no idea how the hell to do that with iptables. So, you're already wrong. :P Heh...sure! And you plan to do it everyday? You can never tell where one would find amusement. :) --- Regards -Prasad http://feedmug.com -- 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: About F19 Firewall
Hello Thomas, - Original Message - From: Thomas Woerner twoer...@redhat.com Subject: Re: About F19 Firewall You have to make sure where you are adding new rules. Here is a simple example where you want to drop everything from 192.168.1.18: If you do it wrong if could end up like this (output of iptables -S): -A INPUT -s 192.168.1.0/24 -j ACCEPT -A INPUT -s 192.168.1.18 -j DROP -A INPUT -j REJECT Yes, I know about the ordering issue. But that is fairly reasonable, intuitive and straightforward to understand. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
