PDFCrack - empty debuginfo file
Hi, I'm trying to package the PDFCrack tool for Fedora, Review request -> https://bugzilla.redhat.com/show_bug.cgi?id=746754 Koji build -> http://koji.fedoraproject.org/koji/taskinfo?taskID=3446368 Somehow it is creating an empty DebugInfo package. Could someone tell why it is creating an empty debuginfo package? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PDFCrack - empty debuginfo file
- Original Message - > From: Josh Boyer > The %build section has: > strip pdfcrack Ah okay, I'll patch the Makefile. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Reviews done, approval pending
Hi, Please see these review requests, PDFCrack -> https://bugzilla.redhat.com/show_bug.cgi?id=746754 ndjbdns -> https://bugzilla.redhat.com/show_bug.cgi?id=480724 Could someone approve these packages please? Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviews done, approval pending
Hello Richard,
- Original Message -
> From: Richard Shaw
> I've just made some comments for PFDCrack, I'll take it once you've
> made the updates.
Ah cool, thanks.
> As for ndjbdns, I'm not quite comfortable with that one. Although I
> hate to mention it because it looks like so much work has already been
> done, I will make one recommendation for it. You probably need to
> create systemd unit files for the tools since it is the default as of
> F15. You can use some %if logic in the spec to use one spec file for
> all releases, i.e.: "%if 0%{?fedora} > 14 ..."
Yeah, even Rahul suggested that one. I'll fix it asap.
Thanks a lot.
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviews done, approval pending
Hi, - Original Message - > From: Tomasz Torcz > Additionaly, I believe daemontools feature are subset of systemd's one. > So daemontools shouldn't be needed at all. Yes, that was removed in the very first release. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
About package review and mismatching md5sums
Hi! :) One of the package review guideline says === MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. === Past couple of days, I've been reviewing the python grapefruit package at - https://bugzilla.redhat.com/show_bug.cgi?id=716808 and the thing is, the spec file provides an - $ svn export -r 31 ... - command to pull the sources and create a tarball using $ tar -czvf ... But as it turns out, it seems, if you create a tarball from the *very same* sources on two different machines, they don't match. As in the md5sum for the two tarball differs. Please try this simple test = $ echo 'Hello, world' > 1 $ tar -cjf 1.tar.bz2 1 $ scp 1.tar.bz2 to a different machine. $ ssh to that same machine $ tar -xjf 1.tar.bz2 -C . $ tar -cjf 2.tar.bz2 1 $ md5sum 1.tar.bz2 2.tar.bz2 d67ea3dac09ed7eee310d9846ecdd879 1.tar.bz2 d4b716716f3cf48139c4112719538513 2.tar.bz2 = Could someone suggest how to fix this glitch? Or the guideline above?? Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About package review and mismatching md5sums
- Original Message - > From: Andreas Schwab > Make sure to disable the gzip timestamp. ...how do you do that? I tried using - $ tar --atime-preserve - etc. but didn't help. Thanks. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About package review and mismatching md5sums
> >From: Aaron Faanes >>$ gzip --help >> -n, --no-name do not save or restore the original name and time stamp >The -j in "tar -cjf" means to compress using bzip2, so I don't think gzip is >used, at least in his example. Yep, gzip or even other compressions are are not used separately; but via tar(1). --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About package review and mismatching md5sums
> >From: Aaron Faanes > >My guess is that the ssh'd host uses a different username/group or uses a >different filesystem. You could compare the two using rsync: Hmmn..strange. Nope, username/group are same, even the file system(ext4) is same. I checked it on 3-4(F11, F14, RHEL6) different machines, everywhere it was different. >If the files differ, it should show up in rsync's itemized changes, like the >following example: Will check this rsync(1) test, should work. Thanks. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need package review
Hi, It's been ages since I filed this pacakge review request. -> https://bugzilla.redhat.com/show_bug.cgi?id=480724 Could someone please review and approve it? Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need package review
- Original Message - > From: Richard Shaw > To: P J P ; Development discussions related to Fedora > > > Not that it would have made a difference in this case but one problem > you have is you've assigned the review request to yourself. It should > be assigned to the reviewer. Anyone looking for a package to review > will skip over it thinking it's already under review. Ah cazy, I'm sorry, I did not assign it to myself. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request - mysqlenum
Hi, Could someone please review this package -> https://bugzilla.redhat.com/show_bug.cgi?id=798738 Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Login problem after yum update
Hi, After I did yum update today morning(May 10'Th), I'm facing a weird login problem. None of the authentications - gdm login, su - user, or ssh from a remote host etc. are being resolved. Even passwd(1) segfaluts while changing password. I just can't login to the machine, in any way. did anyone had the same experience? Below is the yum history of the last update transaction. Thanks. --- Regards -Prasad PS: Please don't send me html/attachment/Fwd mails --- Loaded plugins: presto Transaction ID : 117 Begin time : Mon May 10 10:21:41 2010 Begin rpmdb: 1563:a1f216d158d5c5e3f6d87b0731a9603ce0697ddc End time :10:23:22 2010 (101 seconds) End rpmdb : 1563:1a2db0c1eeb38807145bad96a7cd9800ba241e9b User : pjp Return-Code: Success Transaction performed with: Installedrpm-4.7.2-1.fc12.i686 Installedyum-3.2.27-3.fc12.noarch Installedyum-presto-0.6.2-1.fc12.noarch Packages Altered: Updated evince-2.28.2-1.fc12.i686 Update 2.28.2-2.fc12.i686 Updated evince-djvu-2.28.2-1.fc12.i686 Update 2.28.2-2.fc12.i686 Updated evince-libs-2.28.2-1.fc12.i686 Update 2.28.2-2.fc12.i686 Updated libblkid-2.16.2-7.fc12.i686 Update2.16.2-9.fc12.i686 Updated libblkid-devel-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 Updated libchamplain-0.4.3-1.fc12.i686 Update0.4.5-1.fc12.i686 Updated libchamplain-gtk-0.4.3-1.fc12.i686 Update0.4.5-1.fc12.i686 Updated libuuid-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 Updated libuuid-devel-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 Updated nss-softokn-3.12.4-15.fc12.i686 Update 3.12.4-17.fc12.i686 Updated nss-softokn-devel-3.12.4-15.fc12.i686 Update 3.12.4-17.fc12.i686 Updated nss-softokn-freebl-3.12.4-15.fc12.i686 Update 3.12.4-17.fc12.i686 Updated perl-Digest-HMAC-1.01-21.fc12.noarch Update1.02-1.fc12.noarch Updated perl-URI-1.40-1.fc12.noarch Update1.54-1.fc12.noarch Updated python-fedora-0.3.18-1.fc12.noarch Update 0.3.20-1.fc12.noarch Updated python-virtinst-0.500.1-2.fc12.noarch Update 0.500.1-3.fc12.noarch Updated tigervnc-1.0.0-3.fc12.i686 Update1.0.1-1.fc12.i686 Updated util-linux-ng-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 --- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login problem after yum update
--- On Mon, 10/5/10, David Woodhouse wrote: > Downgrade this. > https://bugzilla.redhat.com/show_bug.cgi?id=504949 Hey thanks, it worked. Thank you. --- Regards -Prasad PS: Please don't send me html/attachment/Fwd mails -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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: 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
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: 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
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: 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
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
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: 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
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: F23 System Wide Change: Default Local DNS Resolver
Hello Miloslav, > On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač 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: 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
Unresponsive upstream - mysqlenum
Hi, I filed mysqlenum package for review more than a month ago. Review is stuck because the upstream is unresponsive about a licensing issue. -> http://www.andreafabrizi.it/?mysqlenum -> https://bugzilla.redhat.com/show_bug.cgi?id=798738 What is a way out in such cases? I'm sure it must have happened before. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PDF printing woes
Hi, I'm facing a weird printing problem with cups-1.5.2 on F16. I can print a document from the browser; But when i try to print a PDF document, it prompts me for the cups server password. I've tried with epdfviewer and Adobe Reader both halt at the same point. === (epdfview:17565): Gtk-CRITICAL **: gtk_box_pack: assertion `child->parent == NULL' failed WARNING: couldn't connect to: /tmp/keyring-cKmdWq/pkcs11: No such file or directory Password for pjp on cups.x.com? (acroread) Gtk-Message: Failed to load module "pk-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module" p11-kit: couldn't load module: /usr/lib/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory Password for pjp on cups.x.com? === Is this some default cups policy issue? Has someone encounterd it before?? Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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: 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č 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
> 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
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: 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
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 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: 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 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 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 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: 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: 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 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
> 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
About F19 Firewall
Hi, I upgraded to F19 recently. And I happened to look at the output of iptables(8) today. $ iptables -nL It's baffling! It's crazy 4 pages long listing!! Why are there so many chains? Most are empty. Those which have rules, jump from one chain to another and that jumps to yet another. Multicast DNS is allowed in the internal network(chain IN_internal_allow). I guess IN_internal_allow is meant for some closed group internal network, not sure. ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353 ctstate NEW Who uses it? Then I looked at the firewall configuration GUI tool. That's even more baffling. On the left hand side, it lists zones: home, internal, public, work etc. without any explanation whatsoever what each one is suppose to do. It also has a default zone which is 'public'. I guess that must be the running firewall configuration. So even if I'm at work or at home, I'm using firewall configuration that is meant for public network, am I? Besides, who is going to switch between these zones everyday from home to work to home again? I think for individual users, which is majority of the users, this is a stupid firewall. It doesn't have to be so complicated that even if one tries to understand it, he/she can not. :( --- 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 Tomasz, - Original Message - > From: Tomasz Torcz > Subject: Re: About F19 Firewall > You seem to have missed this Fedora *18* feature: > https://fedoraproject.org/wiki/Features/firewalld-default > firewall-cmd is supposed to isolate user from all this chains. Yep, true. My contention is not with the tool, but with the complexity it adds to the rules with all the zones and sub-chains and user-space tooling around it. -> https://fedoraproject.org/wiki/FirewallD As I suspected a zone describes a network one is currently connected in. It could be home, work, public(wifi at a coffee shop) etc. That means one must keep shifting from home to work to home and in between public for coffee-shop. I wonder who's going to do that every day. If they don't they either don't get to use the network services or are not protected enough. Ex. one always has the 'public' zone rules activated. > That's mDNS, widely used in zeroconf discovery (for example, printers). I did not mean why is it used, but who needs it. I think for most users such configurations are fairly static that mDNS & avahi can be disabled after their first usage/discovery. Having a service/port open all the time, when you don't need it, isn't a good thing. --- 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
- Original Message -
> From: P J P
> Subject: About F19 Firewall
> It doesn't have to be so complicated that even if one tries to understand it,
> he/she can not. :(
This small script seems to work good.
===
#!/bin/sh
#
# fw.sh: a basic drop unless allowed firewall.
FW='iptables -t filter '
# main
{
$FW -A INPUT -i lo -j ACCEPT;
$FW -A INPUT -p icmp -s 10.x.x.x/16 -j ACCEPT;
$FW -A INPUT -p tcp -s 10.x.x.x/16 -m state --state NEW --dport 22 -j
ACCEPT;
$FW -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT;
$FW -A INPUT -j REJECT --reject-with icmp-host-prohibited;
$FW -A OUTPUT -p tcp -m state --state NEW -s 10.x.x.x/16 -d facebook.com \
-j REJECT --reject-with icmp-host-prohibited
$FW -P INPUT DROP;
$FW -P FORWARD DROP;
exit 0;
}
===
---
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
Hi Mateusz, - Original Message - > From: Mateusz Marzantowicz > Subject: Re: About F19 Firewall > > Wireless networks have unique "names" and are represented as different > connections on NetworkManager (network connection != interface). For > network named "MyHomeNet" one can associate Home zone in > NetworkManager and for network "CoffeShowHotSpot" one assigns Public zone. > You > don't have to change anything once it's assigned. Public zone is as I > understand strictest but usable one (block zone does not allow traffic). > This can also be applied to wired connection. Yep, true.Individual zones for each type of network seems to offer choice and versatility from Firewalld. But a user could end up using the same zone for all networks, because it appears as the default one when doing the network <=> zone assignment in NetworkManager. I don't use NetworkManager so not sure how it works. > I agree they're harder to understand and maintain manually by sysadmin but > they're not designed for such usage. Hmmn, it should have been a package for user to install at will, rather than a replacement of an understandable firewall. Thanks. --- 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, - Original Message - > From: Mateusz Marzantowicz > Subject: Re: About F19 Firewall > > Maybe, true but I doubt that simpler set of rules, that never get > audited, written by inexperienced users are more secure than "complex" > rules in FirewallD which at last had chance to be checked. It's not that simpler rules are more secure, but they come handy if one is to audit them or modify them for his/her set-up. Such modifications could be merged back as user contributions, which only helps to strengthen the tool or set of rules. The thing with complexity is, it keeps, even the able people, away from fiddling with things which I feel sort of beats the whole purpose. As in, if amongst all the available zones, a user is always going to use just one everywhere, it beats the purpose of other zones and the promise of security too, no? Worse is, people would just turn it(Firewalld) off because they can not understand it or make it work for them. > BTW, there is not that much magic in rules applied by FirewallD and > other firewall solutions for Linux have similar level of rule complexity > (ufw, shorewall, etc.) True. We can not avoid complexity. There are complex set-ups & networks, which need complex rules. Firewalld as a tool would be right having features to enable a user who wish to create such complexity and define rules for the same. But providing it by default for individual Fedora users, who don't need it, doesn't feel right. --- 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
Hi, - Original Message - > From: Thomas Woerner > Subject: Re: About F19 Firewall > 1) Separate zones. > NM connections, interfaces and source addresses or ranges can be bound > to zones. The initial default zone is public and all connections will be > bound to this zone. The user or administrator can bind connections to > other zones by either doing this in the NM connection editor or within > the ifcfg file. Yeah, Mateusz explained that earlier. I don't use NM either. > 2) Make sure that a newly added rule will have the desired effect. > > If you are mixing deny and allow rules, you can not say which effect it > will have. Either there are unwanted accepts or rejects or drops. A > simple and straight forward solution is to have separate chains for deny > and allow rules. The same applies also for logging rules. iptables(8) takes action(jumps to target) at the first rule that matches or continues further till it finds a match and falls back to the chain policy if no rule is matched. From the manual: ---TARGETS A firewall rule specifies criteria for a packet and a target. If the packet does not match, the next rule in the chain is the examined; if it does match, then the next rule is specified by the value of the tar‐ get, which can be the name of a user-defined chain or one of the spe‐ cial values ACCEPT, DROP, QUEUE or RETURN. ... If the end of a built-in chain is reached or a rule in a built-in chain with target RETURN is matched, the target specified by the chain policy determines the fate of the packet. --- > You do not need to change it, but you can if you want to. If for example > you are using wifi connections at home, work, .. you can bind these to > the (for you) appropriate zone. For example work for your work wifi > connection. It will be used only if you are connecting to your work wifi > connection (it is bound to the SSID). > > The default zone (initially public) is used for all connections and > interfaces where the zone has not been set to another value. > > You can customize the zones and services according to your needs. Yes, I understand the functionality, but I doubt if it'll be used at all. It's not desktop background that people would want to change everyday. --- 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
Hi, - Original Message - > From: Thomas Woerner > Subject: Re: About F19 Firewall > If a static firewall configuration fits your needs, just disable > firewalld and use the ip*tables firewall services: Static? Oh my...! Firewalld allows Applications, daemons and the user can request to enable a firewall feature over D-BUS. It does not seem like a good idea at all. --- 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
Hi, - Original Message - > From: P J P > Subject: Re: About F19 Firewall > > Static? Oh my...! Firewalld allows Applications, daemons and the user can > request to enable a firewall feature over D-BUS. It does not seem like a good > idea at all. What happens if an application/daemon/user edits firewall rules in a way that puts the user at risk? Isn't that possible?? --- 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 > 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
Re: About F19 Firewall
Hi, - Original Message - > From: Thomas Woerner > Subject: Re: About F19 Firewall > Applications or daemons can only request changes to the firewall if they > are authenticated. Sure. But user authentication is function of the task an application performs and not of the firewall rules it adds or removes. In most cases, user won't even know what firewall rules an application is going to add/edit/remove. Meaning if an authenticated application leaves user's machine vulnerable, that is always going to be a side-effect and not an intended one. Ex. Say I start virt-manager, it prompts me for authentication, I enter password and click [Ok]. It starts libvirtd in the background, creates interfaces, adds firewall rules etc. etc. As a user looking at the GUI, I'm completely oblivious to what it is doing(or did) in the background. This side-effect design is what I think isn't a good idea. --- 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
- Original Message - > From: Thomas Woerner > Subject: Re: About F19 Firewall > O.k., then please provide a program that places (user supplied) rules at > the proper position in an (user supplied) rule set in that way that it > will always result in the (user) expected behaviour without further > modifications. BTW: This is not limited to source addresses only, but > also port ranges and ports, matches, logging, .. > > I am looking forward to get this solution. Heh, iptables(8) is good enough for all of that. Besides, I'm yet to see an individual user who is so fed up of iptables(8) ordering issue that he/she has to write a new application to do that. For most users firewall is hardly 3-4-5 rules, not more. I published my own little script earlier in this thread. Even firewalld's default rule-set is close to 5 actual rules, rest of it is just jumping from one chain to another, 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: About F19 Firewall
- Original Message - > From: poma > Subject: Re: About F19 Firewall >> Ex. Say I start virt-manager, it prompts me for authentication, I enter > password and click [Ok]. It starts libvirtd in the background, creates > interfaces, adds firewall rules etc. etc. > This must be a new feature I haven't heard of. :) Heh...just an example, doesn't really happen like that, but not too far from it either. :) --- 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 > 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
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 > 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 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 > 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 > 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 > 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 > 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 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 > 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: Yum dependency resolving & remove_leaf_only
> On Monday, 14 October 2013 8:05 PM, Eric H. Christensen > 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
Re: Yum dependency resolving & remove_leaf_only
> On Tuesday, 15 October 2013 12:51 PM, Jan Zelený 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
Gnome-shell-extension-weather woes
Hi, So I thought let's get a weather extension to see current weather in my city. Should have been easy like slicing butter, right? It turned out to be crazy disaster!!. 0. I'm using GNOME Shell 3.4.1 on F17 (Beefy Miracle). 1. I do $ yum install gnome-shell-extension-weather. 2. It does not show up in the top panel. So I look around for some option to enable it. I try system settings, no luck. Nowhere do I see option for extensions. 3. On CLI $ gnome-shell- , lists gnome-shell-extension-tool I do -> $ gnome-shell-extension-tool -e gnome-shell-extension-weather still it does not show up in the top panel. 4. $ gnome-shell-extension-prefs It lists the weather extension, I set preferences for temperature, wind speed units etc. and try to add city: Pune, India. Even after 5 minutes the `Ok' button does not come to life. I have absolutely no idea why. After typing few other random cities, I realise it must have been doing web search for the city I typed, for it shows me list of cities as auto-complete list. 5. I type `Pune, India' again and wait 5 minutes. This time it shows the drop down list with Pune at the top. I select it, but still the `Ok' button does not come to life. No Idea why. So I cancel. 6. Try again, type `Pune, India', wait 5 minutes, select Pune from the list, this time `Ok' wakes up, I click it. The `gnome-shell-extension-prefs' dialogue window has no `ok or apply' button, so I click `X (close)' at the top right corner. But the weather extension does not show up in the top panel. 7. I try: Alt+F2 r , still no luck. 8. I log-out of the gnome-shell, and log-in again: and I'm greeted with the infamous - Oops! Something went wrong!! - message. I try to log-in couple more time, but same message. 9. I un-install `gnome-shell-extension-weather' from text console, and try to log-in, still same message. 10. I plug-out the USB datacard (internet) and try to log-in. It works! 11. I install `gnome-shell-extension-weather', set preferences, and log out. USB internet is on, try to log-in - Oops! Something went wrong!! 12. disconnect internet, try to log-in and it works. 13. Yet, weather extension is nowhere to be seen on the top panel or task bar. :( This is just bad state of affairs and *terrible* user experience @gnome-shell-weather-extension! :( Has anybody tried this extension before? Does it work?? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell-extension-weather woes
Hello Steven, > From: Steven Boswell II >Subject: Re: Gnome-shell-extension-weather woes >I don't have a gnome-shell-extension-weather package installed, but I see the >weather anyway. How do you see weather anyway? gnome-shell shows it?? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell-extension-weather woes
Hey hi, - Original Message - > From: Rahul Sundaram > Subject: Re: Gnome-shell-extension-weather woes > https://bugzilla.rpmfusion.org/show_bug.cgi?id=2017 > https://bugzilla.rpmfusion.org/show_bug.cgi?id=2516 > Perhaps you can provide the info there. However one quick route is to try Thanks for the links. I'll post information there. > https://extensions.gnome.org/extension/613/weather/ I tried this. On FF it prompts me to install `weather' extension, though I already have it installed. On chromium it says: === You do not appear to have an up to date version of GNOME3. You won't be able to install extensions from here. See the about page for more information. === If I do install from the web-page, where would it install? Is there a way to do uninstall?? Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell-extension-weather woes
> From: Steven Boswell II >Subject: Re: Gnome-shell-extension-weather woes >Maybe it's because I'm running GNOME3 in "fallback" mode. >I can't stand the new GNOME GUI. Heh...I see! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell-extension-weather woes
- Original Message - > From: Rahul Sundaram > Subject: Re: Gnome-shell-extension-weather woes > http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html. > By default, in ~.local/share/gnome-shell/extensions Cool...thanks! :) --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
logrotate(8) and copytruncate as default
Hi, Recently I've seen multiple issues related to new file creation by logrotate(8). A race condition described by [1], between creation of a new file and setting file permissions and acl(5). Another I came across in ndjbdns [2], as it continued to write to an open, but rotated log file. Wouldn't it be better to make 'copytruncate' as default behaviour for logrotate(8)? Instead of renaming an old file and creating a new one. [1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1098 [2] https://github.com/pjps/ndjbdns/commit/be5fd0c90376b5c89e5b5dc3d57f64d905afe519 Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Jan, - Original Message - > From: Jan Kaluža > Subject: Re: logrotate(8) and copytruncate as default > This is usually fixed by sending some signal to daemon in postscript > informing it that logs should be reopened. That way, no messages are > lost. The worst thing which can happen is that some messages get logged > in the rotated file for short time (after rename is done by logrotate > and before daemon reopens the new log). Right, I did try that, but it does not help. Because 'ndjbdns' servers run inside a chroot(1) jail. At start-up these servers open the log file under - /var/log/ - and change root directory to a secure location. Now when logrotate(8) rotates the file, even if it signals to a DNS server that it needs to start writing to a newly created file, server can't do it because - /var/log - is not visible/accessible from inside a chroot(1) jail. > If you use copytruncate, there is chance that some messages get lost (as > stated in man logrotate). Making it default could surely make things > much easier and less error-prone, but I'm afraid we just can't remove > old behaviour completely right now and therefore it wouldn't save > anything regarding the problems you have mentioned. I'm not sure if there would be much of data loss during copy-truncate. Because that time window is tiny small. It is a similar race condition issue as the current one, but much less severe. There's no chance of unprivileged user access etc. I also doubt if making copy-truncate default behaviour would break any packages which depend on logrotate(8) to rotate their logs. > I'm not sure right now if the benefits of the "copytruncate" usage > are strong enough in comparison with the possibility to lost the messages > during rotation. I think we should try to evaluate for real how much data is lost, if any. > I will definitely try it and see how bad it is, but I presume for bigger > logs it could be a problem. That's cool! Please do let me know if I could help in any way. > Maybe it's just better to try to fix existing bugs and not abandon the > "rename and reopen" way completely? Well, existing bugs would be fixed anyway. I'm not saying we abandon rename and reopen completely, may be we could provide it as an option in place of 'copytruncate' say - 'createlog' or 'renamelog' or something like that. Thanks so much! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Jan, - Original Message - > From: Jan Kaluža > Subject: Re: logrotate(8) and copytruncate as default > > I'm not sure right now if the benefits of the "copytruncate" usage are > strong enough in comparison with the possibility to lost the messages > during rotation. I did a small experiment to test how much data loss would incur in copy-truncate. First command constantly writes to a file. While the second one uses an exclusive lock to temporarily halt the write operation, do a copy, truncate and release the exclusive lock so that the write continues where it was stopped. === $ cd /tmp/exp/ # Following command continuously writes to a file. # $ (count=0; while(true); do count=`expr $count + 1`; \ echo `date "+%d %a %Y %T"` $count; done >> test.log &) # Following command uses exclusive lock to halt the write # operation, perform copy-truncate, and release the lock. # $ flock -x test.log -c 'cp test.log test.log.1; > test.log' $ $ $ tail -n -4 test.log.1 27 Thu 2013 21:14:14 7317 27 Thu 2013 21:14:14 7318 27 Thu 2013 21:14:14 7319 27 Thu 2013 21:14:14 7320 $ head -n 4 test.log 27 Thu 2013 21:14:14 7321 27 Thu 2013 21:14:14 7322 27 Thu 2013 21:14:14 7323 27 Thu 2013 21:14:14 7324 === As can be seen above, there does not seem to be any data loss at all. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hi, - Original Message - > From: Jan Kaluza > Subject: Re: logrotate(8) and copytruncate as default > Right now, without locking, logrotate would loss more messages if the > logs are big, because copying takes more time. It would be interesting > to mention the file size in your tests too. But as I said, if the > exclusive lock pauses the writing operations to the lock file, you > won't be able to reproduce it with your current reproducer. I can understand, if log files run into GBs, copying those would take time, and till that time kernel will have to buffer those suspended write operations and corresponding data. I'll try another experiment. Let's let the first command create large(1-2 GB) log file, and then do flock, followed by copy-truncate. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
- Original Message - > From: Colin Walters > Subject: Re: logrotate(8) and copytruncate as default > It's worth noting that all of these problems go away with the systemd > journal. Oh, how does systemd rotate files? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Miloslav, - Original Message - > From: Miloslav Trmač > Subject: Re: logrotate(8) and copytruncate as default > > That's a possible argument for changing the ndjbdns logging/logrotate > configuration, AFAICS not an argument for changing the default. Yes, 'ndjbdns' has already fixed this issue by using 'copytruncate'. Change was not suggested only for ndjbdns, but together with another race condition and in anticipation of other such issues which we aren't aware of. Default copy-truncate appears to address all those. IMHO, renaming a file which is being written to by another application does no feel right. > _Any_ data loss during normal operation is _unacceptable_. Sure! As per the experiment so far, there is no data loss at all. > The rename+create new file+SIGHUP+reopen "protocol" is both safe and > widespread. Safe? There is a race condition in it for which a CVE has been assigned. And if anything, its widespread usage only increases the concern. > "copytruncate" is not at all an alternative on equal footing because > it can, and sooner or later _will_, loose data. We could invent some > kind of "suspend logging signal"+copytruncate+"resume logging > signal" protocol I suppose, but that puts the burden of suspending logging on > the application, and still has a larger risk of data loss (if the > application crashes after trying to log a message). I think we are yet to know for sure if there would be any data loss. > If the way ndjbdns logs is inherently prone to losing data, that's a > fairly severe bug that needs fixing. Using "copytruncate" in the > ndjbdns configuration is at best an incomplete workaround. ndjbdns logging is not prone to losing data. And It already uses copytruncate to continue writing to a proper file after logs have been rotated by logrotate(8). --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Mirek, - Original Message - > From: Miloslav Trmač > Subject: Re: logrotate(8) and copytruncate as default > > * logrotate reads all contents of file until EOF > * application appends one more data line > * logrotate calls truncate() I see. Thanks for these input, will consider these during further experiments. I wonder how will application append one more line, if the file is locked. > (And yes, journald solves that by integrating the log rotation with > the log writer, which is a better design, and there's no inherent > reason why rsyslog couldn't be doing something similar. Then there > are only the dozens? of applications that don't go through syslog at > all and write their own log files to also handle...) Ah okay. So, journald does both logging data and rotating files. Interesting. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Lennart, Colin, - Original Message - > From: Lennart Poettering > Subject: Re: logrotate(8) and copytruncate as default > > The systemd-journald takes care of all of: receiving messages, writing > them to storage, and rotating the storage. > > We do synchronous rotation before each write. i.e. the moment we append > to a file we check if the write would cause the disk usage to be out of > limits, and then do the rotation right away. I see. While doing this rotation, I guess systemd uses flock(2) or similar mechanism to pause writing to a log file, move/rename or copy-truncate that file and continue writes again? > You can configure how much disk space journald should take up at max, > and how much you want to remain free. > > You can also configure a time limit, to enforce that everything older > than a certain time is always cleaned up (though this is really > something for weird data retention policy setups, normal users should > not need it, disk space is a much more useful limiter). Ah, cool! That's interesting. Thanks so much for this insight. Thank you! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Jan, - Original Message - > From: Jan Kaluza > Subject: Re: logrotate(8) and copytruncate as default > > I think difference between systemd and logrotate in this case is that > logrotate is not owner of the logs it rotates. It has no control of writing > to them. I haven't checked that journald code, but journald definitely > controls the log and is (correct me if I'm wrong) the only application > writing to it. > Therefore it's not problem for journald to just write some line to log, > check that the log is too big and rotate it. It doesn't have to do any locking > to stop writing, it just does not write any data there during rotation. Ah, yep true. In my head I kept thinking application is writing to a file. Right, locking wouldn't be required if journald is the sole writer to a file. Thank you! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Jan,
- Original Message -
> From: Jan Kaluza
> Subject: Re: logrotate(8) and copytruncate as default
>
> Right now, without locking, logrotate would loss more messages if the
> logs are big, because copying takes more time. It would be interesting
> to mention the file size in your tests too.
===
#!/bin/sh
#
# flockexp.sh: is a simple experiment to create a large log file and
# copy-truncate it when its size reaches a predefined limit.
#
if [ $# -lt 2 ]; then
echo "Usage: $0 ";
exit 0;
fi
# main
{
> $1;
logsize=$2;
watch "if [ \`stat -c '%s' $1\` -gt $logsize ]; " \
"then flock -x $1 -c 'cp $1 $1.1; > $1'; fi" > /dev/null &
count=0;
while (true);
do
count=`expr $count + 1`;
echo `date "+%d %a %Y %T"` $count `grep 'MemFree' /proc/meminfo`;
done >> $1;
}
===
I tried it with different file sizes. It starts showing data loss as size
grows > 2MB.
===
$ stat -c '%s' test.log test.log.1
418065
2007074
$
$ tail -n 4 test.log.1
28 Fri 2013 17:20:28 42937 MemFree: 3655640 kB
28 Fri 2013 17:20:28 42938 MemFree: 3655580 kB
28 Fri 2013 17:20:28 42939 MemFree: 3655068 kB
28 Fri 2013 17:20:28 42940 MemFree: 3655436 kB
$
$ head -n 4 test.log
28 Fri 2013 17:20:28 42942 MemFree: 3655428 kB
28 Fri 2013 17:20:28 42943 MemFree: 3655448 kB
28 Fri 2013 17:20:28 42944 MemFree: 3655812 kB
28 Fri 2013 17:20:28 42945 MemFree: 3655824 kB
===
I guess kernel buffers start dropping writes after very short limit.
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hi, - Original Message - > From: Lennart Poettering > Subject: Re: logrotate(8) and copytruncate as default > > journald is the only writer, it doesn't need locking. The changes it > does are done in a way so that concurrent readers will either see the > changes or not, but never half-written changes. I see. How is that done? Does journald also renames the current file and creates a new one and continues writing to that new file?? I'm asking because, if not, then journald could also suffer from the same buffering issue that kernel seems to do with locking. Ie. As the file size grows copy-truncate takes time, kernel is unable to buffer all the writes that happen during that time, so it starts dropping a few, which results in data loss. > Also note that locking on Linux is seriously broken. You can get a lock > on any file you can read, thus you can freeze everybody else who might > want a lock. Or in other words: if a logging daemon takes a lock on its > lock files, then you can use this to make that service freeze forever. Yeah, I realised that. I posted a small script earlier in this thread. With locking, you start seeing data loss as the file size grows >= 2MB. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
- Original Message - > From: Lennart Poettering > Subject: Re: logrotate(8) and copytruncate as default > It will create a new file and rename the old one. Right, thanks for confirming! Thank you! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
