Search results for "dnsmasq" - Fedora mailing-lists

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

by Doug Ledford

On 03/01/2010 05:01 PM, Jesse Keating wrote: > On Mon, 2010-03-01 at 16:51 -0500, Doug Ledford wrote: >> To be pedantic, Fedora is what it is. What the leadership has to say >> doesn't really matter in terms of what Fedora *is*, only in terms of >> what Fedora is *supposed to be*. In order to know what Fedora really >> is, a person would need to look over the updates that have been pushed >> to F-11 and F-12 and compare those to what's in rawhide and maybe F-13 >> and see if wholesale package updates are being reserved for rawhide or >> if wholesale updates are being pushed on down into the stable releases. >> At that point you would know for sure what Fedora is, not what it's >> supposed to be. I say this because, obviously, different people read >> the part about First differently and do different things. > > Right, there are obviously people who feel that what Fedora Is is > "broken". The status quo isn't working, and that's why FESCo or members > of FESCo are trying to come up with ways to fix that. A lot of the > argument here seems to be disagreement about what Fedora Should Be, > which is precisely an issue the Fedora board has been struggling with. Which is when I point out that I, personally, like the Mandriva way of doing things: Bugfixes/Backports as the two update streams with different goals and allowed updates. I would prefer to have my home server on Bugfixes, and my desktop environment on Backports. But, I could almost guess that a reasonable compromise between the two update stream model and the single update stream model would be to have a single update stream, but to treat all those apps normally thought of as server apps (database servers, dhcp, bind, dnsmasq, dovecot, sendmail, exim, postfix, blah, blah) as though they existed under the bugfix model and treat those things most closely related to the day to day user experience (firefox, thunderbird, gnome, kde, pulseaudio, openoffice) under the backport model. Dunno, could be wrong there. Maybe I'm the only one that draws that particular line between the packages he would like to see updated versus the ones he wants to see targeted fixes only in. If you asked me the same question with my fedora packager hat on, then I prefer updates in stable releases so I can copy my spec, sources, clog, and patch files from devel to F-13/F-12/F-11 and just keep everything in sync. I freely admit that this is purely a convenience thing for me. However, I think this clearly demonstrates that doing backports + bugfixes is no more work than doing devel + bugfixes as the bakcports is mainly just a copy, build, release cycle that takes no real time. It's keeping bugfix releases separate from the new releases that takes time and effort. Some people do that now, some don't. For those that do, the two stream model would probably be an easy change. For those that don't, it would be seen as burdensome since it would be adding the bugfix side, not the backport side. Oh, since it was implied several times in this thread by a couple different people, I feel obliged to point out that I don't think it's appropriate to assume that if someone wants a stable release then they should be on Fedora N-1. I've had machines that were on Fedora N-1 until it became N-2, at which point I upgraded to N. That I leap frogged had nothing to do with whether or not I wanted a stable stream. Well, it sorta did, the 6 month release cycle was too fast and I put off upgrading until 1 year passed, and I didn't want to have to upgrade for another year so I had to jump to N. The fact that I went to N instead of N-1 doesn't imply that I want a mainly rolling update now and to infer so would be incorrect. -- Doug Ledford <dledford(a)redhat.com> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband

14 years, 3 months

Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen / dom0 testing instructions

by Pasi Kärkkäinen

On Wed, Sep 14, 2011 at 05:45:39PM +0300, Pasi Kärkkäinen wrote: > > > > > > ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us > > > > to setup test environment, and would be good to have some info in advance. > > Ok, so some basic steps to test Xen dom0 functionality in Fedora 16: - Install Fedora 16 Beta TC2 host, to become Xen dom0. Installable ISO images available here: http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Fedora/ (and LIVE ISO's here: http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Live/). - Disk partitioning on the host: First partition should be /boot as ext3, for the rest of the disk use LVM volume group, and remember to leave free space in the volume group so you can later after installation create LVM volumes for the VMs. See these tutorials for an example about disk partitioning: http://wiki.xen.org/xenwiki/Fedora13Xen4Tutorial http://wiki.xen.org/xenwiki/RHEL6Xen4Tutorial - After Fedora 16 is installed and everything works properly on baremetal, including Internet access, proceed to installing Xen and virtualization related packages: yum install xen xen-hypervisor xen-runtime libvirt virt-manager virt-viewer xorg-x11-xauth - Enable automatic start of xend and libvirtd chkconfig xend on chkconfig libvirtd on chkconfig --list xend chkconfig --list libvirtd - Add a suitable grub entry for Xen. This grub entry is just an example, keep your own root device uuids/names etc and modify to suit your setup: menuentry 'Xen dom0, Fedora Linux 3.1.0-rc6' --class fedora --class gnu-linux --class gnu --class os { load_video insmod part_gpt insmod ext2 set root='(hd0,gpt2)' search --no-floppy --fs-uuid --set=root 6b84e53a-8a3a-4465-ac5a-c1c98758e448 multiboot /xen-4.1.gz placeholder dom0_mem=1024M loglvl=all guest_loglvl=all console_to_ring cpuidle=xen echo 'Loading Linux 3.1.0-rc6 ...' module /vmlinuz-3.1.0-rc6 root=/dev/mapper/VolGroup00-lv_root ro rd.md=0 rd.dm=0 KEYTABLE=us debug loglvel=8 rd.lvm.lv=VolGroup00/lv_swap SYSFONT=latarcyrheb-sun16 rd.luks=0 rd.lvm.lv=VolGroup00/lv_root LANG=en_US.UTF-8 echo 'Loading initial ramdisk ...' module /initramfs-3.1.0-rc6.img } grub entries will be automatically generated later, but currently grub/grubby does not have all required patches to do it automatically. - Reboot to Xen dom0! - Verify Xen and xend works: xm info xm list - Verify you have a bridge called "virbr0" (use: "brctl show"). It should get created by libvirtd. There should be a "dnsmasq" process running for virbr0 providing that bridge a DHCP server with private IPs, dns relay and NAT to internet, so you can use it for VM network installations. - Install a Fedora 15 Xen PV domU: First create a new LVM volume for the VM: lvcreate -L30G -nf15_disk1 /dev/VolGroup00 (Replace VolGroup00 with your VG name.. use "vgdisplay" to check.) Start actual installation: virt-install -d -n f15 -r 1024 --vcpus=1 -f /dev/VolGroup00/f15_disk1 --vnc -p -l "ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/…" (replace the URL with your local Fedora mirror site). virt-install will open a virt-viewer (VNC) graphical window of the guest console (pvfb) where you can do the Fedora installation as usual. - Install and test various other types of VMs, both PV and HVM. - Try using file: disk backend (image files) aswell. - Try using graphical "virt-manager" GUI to install Xen VMs. - Disable automatic start of xend, reboot, and test xl / libxl, also with virt-manager/virt-install. That should get you started with testing. Btw. I noticed some issues installing F16 Alpha Xen PV domU, so F16 needs some more investigation/debugging before F16 final. -- Pasi

12 years, 9 months

Re: F22 System Wide Change: Default Local DNS Resolver

by Tomas Hozza

On 01/13/2015 08:56 PM, William B wrote: >> To install a local DNS resolver trusted for the DNSSEC validation >> running on 127.0.0.1:53. This must be the only name server entry >> in /etc/resolv.conf. > > .... snip ... > >> People use Fedora on portable/mobile devices which are connected to >> diverse networks as and when required. The automatic DNS >> configurations provided by these networks are never trustworthy for >> DNSSEC validation. As currently there is no way to establish such >> trust. > > > I have a number of concerns about the "readiness" of the proposal. > > Right now, enabled unbound and dnssec-trigger on a laptop is an > extremely difficult experience. I have since taking up this challenge > found that turn it off and on again, has become the default solution on > my linux install now as a result of these problems. Personally I have completely different experience. I have unbound and dnssec-trigger on by default and it works at home, on WiFi, at work, with VPN... > For example, crashes in unbound that are not caught in abrt, forwarders > that do not get added (but they display in the list), queries that > don't ever get replies (But they work when you by-pass unbound to your > glibc forwarder), inability to flush dnscache without sudo, and that > dns caches are held over network boundaries to name a few of my > concerns. Did you file an issue to ABRT (or anywhere?) As for the cache, are you able to do that with dnsmasq? Without sudo you can't even change /etc/resolv.conf. I think we disagree on what should non-privileged user should be allowed to do. > As a result, at this time, enabling this on your system is actually > more of a deteriment that the "benefit" being touted. I would prefer > working DNS over non working "secure" dns. (I guess it's secure because > I can send any traffic out). Yes, without DNSSEC all the hackish network setups just work. >> 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]) > > Unbound creates more flakiness than it solves. Unbound caches "no > answer" as a negative cache entry. If your wireless blips for an > instant, that's it, result vanishes. > > > I think that there should be a large amount of QA focus on this change. > Configurations involving split-view dns should be involved in testing, > testing stability of unbound between suspend/resume, or even > NetworkManager restarts, testing that quieries resolve in esoteric > networks (IE networks that capture and redirect DNS traffic). We will be more than happy to receive any test cases and use-cases (with steps to setup) and use them for testing the readiness of the Change. However more than a relatively non-technical discussion about unclear use-cases that we are unable to reproduce due to insufficient information, we would welcome clear descriptions and clear statements describing what specifically is not working as it should. > This is a change, that currently, has the potential to seriously damage > the user experience of anyone using fedora. I think that much more > rigorous testing and thought should go into this before we just steam > ahead. If in it's current state you install unbound, you will begin to > notice little issues quickly, especially on laptops. That is not a > defalt we should aim for. We are willing to work on resolving user issues. If the change will be proven not ready, we are ready to work on issues and deffer it to F23. However from the past experience there is no way everyone will be happy with the changes, regardless of what those changes are. > NOTE: I'm not just raging here, I actually have opened BZ's for these > issues that I have. I think that awareness of these issues is low, and > that it should be brought to light. I hope that more thorough testing > is carried out in a wider set of environments to eventually get this to > a point where it's a seamless change to enable this service. However at > this time, that is not the case. We are thankful for your contributions in testing the setup. Hopefully you recognize some of the improvements done based on your reports. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com

9 years, 5 months

Re: default local DNS caching name server

by Chuck Anderson

On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote: > On Sat, 12 Apr 2014, Chuck Anderson wrote: > > >Okay, so here is where you and I differ then. We need a solution to > >run everywhere, on every system, in every use case. > > Sounds like wanting ponies? Obviously I fully agree with a solution that > works everywhere, all the time, for everyone, however the want it :) > > > The local DNS > >daemon (note that I didn't say "cache" this time) should be a part of > >the Base OS like init/systemd is. It should be small, unobtrusive, > >and do very little, namely the one thing we need: handle failover > >between multiple DNS servers. I would use the term "DNS proxy" but > >that term is too overloaded with other connotations and preconceived > >ideas. > > Handling failover requires keeping state of previous queries and > outstanding requests to determine which servers are bad or not. Mind > you, unbound allows you to set a max TTL on any record received using > cache-max-ttl=0, so you can very easilly implement this idea. I think > it is a bad idea, because your solution violates your own principle > above: it interferes with my use case of optimising DNS caches, reducing > unneccessary latency, and doing things like pre-fetching of low TTL > records. Of course there would be /some/ state kept. It just wouldn't cache the data, it would only use the state of recent queries and response times to determine if that resolver was dead and start sending those queries to another resolver. It would basically do exactly what glibc's stub resolver does now, but ONCE for the entire system rather than having each process do that independently. I would want this daemon to be as lightweight as possible to minimize any interference with optimising DNS caches, latency, etc. and so that it could be used everywhere, just like systemd is used on all Fedora systems and some form of "init" is used on all Linux systems. Another way to think of this is to separate out the built-in logic in unbound/BIND/dnsmasq/etc. that determines when an authoritative server is dead and apply it to all queries that are made by glibc's stub resolver. Or separate out the logic that glibc uses to determine when a nameserver in /etc/resolv.conf is dead and make that a system-wide daemon. > In DNS, the publisher of data tells you how long the data should be valid > for. If they want the record not to be cached at all, they can set the TTL > to 0. Why should we deploy a daemon that does not provide the very useful > feature of caching in general (especially when doing DNSSEC validation) > when people who wish to not get cached already have a means out, publish > records with TTL=0? If you want to be Akamai, you can! Because things get messy once you start caching on the end-user system. Sure, you can optionally have that messiness (and I'd argue that for Fedora Workstation that would be a sane default) but for Fedora Server I think it is too heavyweight of a solution to run everywhere, and you agreed that running this in VMs is probably not desired. If the lightweight dnslookupd process is configured to forward the request to a local unbound+dnssec-triggerd, then everything from that point will work in the same way it does today with local caching, TTL handling, DNSSEC, etc. But that should be /optional/. I'm arguing that dnslookupd should be on by default everywhere. > >dnslookupd keeps track of up/down DNS servers via some health check > >mechanism, and switches between them appropriately. > > I tend to call heartbeats/keepalives "make deads". They often do the > opposite. Why invent a whole new health check protocol when you can > simple send DNS queries and use strategies to prefer the nearest/fastest > servers already. These kind of selection/preference protocols are part > of any decent DNS implementation. There is no need to re-invent the > wheel. It doesn't need to do active heartbeats--it could passively watch queries/responses that it is forwarding to the resolver and decide based on that if a server is dead and stop querying it until the next one fails, etc. just like glibc does today. For the use cases you desire with full caching and DNSSEC, dnslookupd shouldn't get in the way. All applications/glibc would query 127.0.0.1, which would immediately forward all those requests to the local unbound+dnssec-triggerd setup. Dnslookupd would only take action if unbound died for some reason (and if there was an alternate DNS resolver to switch to).

10 years, 2 months

Fedora EPEL 6 updates-testing report

by updates＠fedoraproject.org

The following Fedora EPEL 6 Security updates need testing: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0835/asterisk-1.8.… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0928/libpng10-1.0.… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0929/drupal7-ctool… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0349/bugzilla-3.4.… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0927/openstack-nov… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0921/trytond-1.8.6… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0850/drupal6-date-… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0763/php-pear-CAS-… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0795/nginx-1.0.14-… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0916/openstack-key… https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-4701/supybot-gribb… The following builds have been pushed to Fedora EPEL 6 updates-testing ddclient-3.8.1-1.el6 drupal7-ctools-1.0-1.el6 gambit-c-4.6.5-1.el6 gtk-chtheme-0.3.1-11.el6 keepalived-1.2.2-3.el6 libpng10-1.0.59-1.el6 msktutil-0.4.1-1.el6 opendnssec-1.4.0-0.a1.el6.2 openscada-0.7.2-4.el6 openstack-keystone-2012.1-0.12.rc1.el6 openstack-nova-2011.3.1-8.el6 python-eventlet-0.9.16-5.el6 python-keystoneclient-2012.1-0.5.e4.el6 python-requests-0.10.6-3.el6 relevation-1.1-3.el6 rubygem-dynect_rest-0.4.1-1.el6 trytond-1.8.6-1.el6 Details about builds: ================================================================================ ddclient-3.8.1-1.el6 (FEDORA-EPEL-2012-0926) Client to update dynamic DNS host entries -------------------------------------------------------------------------------- Update Information: New upstream, bugfix release. -------------------------------------------------------------------------------- ChangeLog: * Thu Mar 29 2012 Jon Ciesla <limburgher(a)gmail.com> - 3.8.1-1 - Latest upstream, BZ 720627. * Thu Feb 10 2011 Robert Scheck <robert(a)fedoraproject.org> 3.8.0-4 - Replaced Requires(hint) by Requires as RPM 4.9 dropped support * Tue Feb 8 2011 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild -------------------------------------------------------------------------------- References: [ 1 ] Bug #720627 - ddclient-3.8.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=720627 -------------------------------------------------------------------------------- ================================================================================ drupal7-ctools-1.0-1.el6 (FEDORA-EPEL-2012-0929) This suite is primarily a set of APIs and tools for other Drupal modules -------------------------------------------------------------------------------- Update Information: Update to upstream release 1.0, including fix for SA-CONTRIB-2012-054 -------------------------------------------------------------------------------- ChangeLog: * Thu Mar 29 2012 Jared Smith <jsmith(a)fedoraproject.org> - 1.0-1 - Update to upstream 1.0 release * Wed Mar 28 2012 Jared Smith <jsmith(a)fedoraproject.org> - 1.0-0.2.rc2 - Update to upstream rc2 release * Fri Jan 13 2012 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 1.0-0.2.rc1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild -------------------------------------------------------------------------------- References: [ 1 ] Bug #808002 - Drupal's ctools 7.x-1.0 module has been released https://bugzilla.redhat.com/show_bug.cgi?id=808002 -------------------------------------------------------------------------------- ================================================================================ gambit-c-4.6.5-1.el6 (FEDORA-EPEL-2012-0920) Scheme programming system -------------------------------------------------------------------------------- Update Information: - Latest upstream release - [EPEL6] ppc64 target is temporarily disable, broken since 4.6.4 -------------------------------------------------------------------------------- ChangeLog: * Thu Mar 29 2012 Michel Salim <salimma(a)fedoraproject.org> - 4.6.5-1 - Update to 4.6.5 - Drop termite subpackages, they have been disabled for many releases - Disable ppc64 target for now; broken since 4.6.4 * Wed Feb 15 2012 Michel Salim <salimma(a)fedoraproject.org> - 4.6.4-1 - Update to 4.6.4 -------------------------------------------------------------------------------- References: [ 1 ] Bug #790373 - gambit-c-4.6.5 is available https://bugzilla.redhat.com/show_bug.cgi?id=790373 -------------------------------------------------------------------------------- ================================================================================ gtk-chtheme-0.3.1-11.el6 (FEDORA-EPEL-2012-0938) Gtk+ 2.0 theme preview and selection made slick -------------------------------------------------------------------------------- Update Information: Built for epel-6. -------------------------------------------------------------------------------- References: [ 1 ] Bug #604501 - Review Request: gtk-chtheme - Gtk+ 2.0 theme preview and selection made slick https://bugzilla.redhat.com/show_bug.cgi?id=604501 -------------------------------------------------------------------------------- ================================================================================ keepalived-1.2.2-3.el6 (FEDORA-EPEL-2012-0922) High Availability monitor built upon LVS, VRRP and service pollers -------------------------------------------------------------------------------- Update Information: Fix IPv4 address comparison. -------------------------------------------------------------------------------- ChangeLog: * Tue Mar 20 2012 Ryan O'Hara <rohara(a)redhat.com> 1.2.2-3 - Fix IPv4 address comparison (#768119). -------------------------------------------------------------------------------- References: [ 1 ] Bug #768119 - keepalived reload does not remove real server https://bugzilla.redhat.com/show_bug.cgi?id=768119 -------------------------------------------------------------------------------- ================================================================================ libpng10-1.0.59-1.el6 (FEDORA-EPEL-2012-0928) Old version of libpng, needed to run old binaries -------------------------------------------------------------------------------- Update Information: This update includes a fix for a potential memory corruption issue (CVE-2011-3048). -------------------------------------------------------------------------------- ChangeLog: * Thu Mar 29 2012 Paul Howarth <paul(a)city-fan.org> 1.0.59-1 - update to 1.0.59 - revised png_set_text_2() to avoid potential memory corruption (CVE-2011-3048) - prevent PNG_EXPAND+PNG_SHIFT doing the shift twice -------------------------------------------------------------------------------- References: [ 1 ] Bug #808139 - CVE-2011-3048 libpng: memory corruption flaw https://bugzilla.redhat.com/show_bug.cgi?id=808139 -------------------------------------------------------------------------------- ================================================================================ msktutil-0.4.1-1.el6 (FEDORA-EPEL-2012-0939) Program for interoperability with Active Directory -------------------------------------------------------------------------------- Update Information: New package. Msktutil is a program for interoperability with Active Directory that can: * Create a computer account in Active Directory * Create a system Kerberos keytab * Add and remove principals to and from that keytab * Change the computer account's password -------------------------------------------------------------------------------- References: [ 1 ] Bug #713313 - Review Request: msktutil - Program for interoperability with Active Directory https://bugzilla.redhat.com/show_bug.cgi?id=713313 -------------------------------------------------------------------------------- ================================================================================ opendnssec-1.4.0-0.a1.el6.2 (FEDORA-EPEL-2012-0930) DNSSEC key and zone management software -------------------------------------------------------------------------------- Update Information: Initial release of opendnssec for EL6 -------------------------------------------------------------------------------- References: [ 1 ] Bug #711899 - Review Request: opendnssec - DNSSEC key and zone management software https://bugzilla.redhat.com/show_bug.cgi?id=711899 -------------------------------------------------------------------------------- ================================================================================ openscada-0.7.2-4.el6 (FEDORA-EPEL-2012-0923) Open SCADA system project -------------------------------------------------------------------------------- Update Information: Rebuild for CentOs 6.x -------------------------------------------------------------------------------- ChangeLog: * Wed Mar 14 2012 Aleksey Popkov <aleksey(a)oscada.org> - 0.7.2-4 - Rebuild for Centos 6.x * Thu Dec 8 2011 Aleksey Popkov <aleksey(a)oscada.org> - 0.7.2-3 - Fixed of source code for build on the el5. - Fixed of Source0 and Source1 directives. - Some cosmetics. * Thu Dec 8 2011 Aleksey Popkov <aleksey(a)oscada.org> - 0.7.2-2 - Some cosmetics. -------------------------------------------------------------------------------- ================================================================================ openstack-keystone-2012.1-0.12.rc1.el6 (FEDORA-EPEL-2012-0916) OpenStack Identity Service -------------------------------------------------------------------------------- Update Information: Update from Diablo to Essex RC1! -------------------------------------------------------------------------------- ChangeLog: * Sat Mar 24 2012 Alan Pevec <apevec(a)redhat.com> 2012.1-0.12.rc1 - upate to final essex rc1 * Wed Mar 21 2012 Alan Pevec <apevec(a)redhat.com> 2012.1-0.11.rc1 - essex rc1 * Thu Mar 8 2012 Alan Pevec <apevec(a)redhat.com> 2012.1-0.10.e4 - change default catalog backend to sql rhbz#800704 - update sample-data script - add missing keystoneclient dependency * Thu Mar 1 2012 Alan Pevec <apevec(a)redhat.com> 2012.1-0.9.e4 - essex-4 milestone - change default database to mysql - switch all backends to sql - separate library to python-keystone -------------------------------------------------------------------------------- References: [ 1 ] Bug #807346 - CVE-2012-1572 openstack-keystone: extremely long passwords can crash Keystone [epel-6] https://bugzilla.redhat.com/show_bug.cgi?id=807346 -------------------------------------------------------------------------------- ================================================================================ openstack-nova-2011.3.1-8.el6 (FEDORA-EPEL-2012-0927) OpenStack Compute (nova) -------------------------------------------------------------------------------- Update Information: CVE-2012-1585: Long server names grow nova-api log files significantly -------------------------------------------------------------------------------- ChangeLog: * Thu Mar 29 2012 Pádraig Brady <P(a)draigBrady.com> - 2011.3.1-8 - Remove the dependency on the not yet available dnsmasq-utils * Thu Mar 29 2012 Russell Bryant <rbryant(a)redhat.com> - 2011.3.1-7 - CVE-2012-1585 - Long server names grow nova-api log files significantly - Resolves: rhbz#808148 * Mon Mar 26 2012 Mark McLoughlin <markmc(a)redhat.com> - 2011.3.1-6 - Avoid killing dnsmasq on network service shutdown (#805947) * Tue Mar 6 2012 Pádraig Brady <P(a)draigBrady.com> - 2011.3.1-5 - Require bridge-utils * Mon Feb 13 2012 Pádraig Brady <P(a)draigBrady.com> - 2011.3.1-4 - Support --force_dhcp_release (#788485) * Fri Jan 27 2012 Pádraig Brady <P(a)draigBrady.com> - 2011.3.1-3 - Suppress erroneous output to stdout on package install (#785115) -------------------------------------------------------------------------------- References: [ 1 ] Bug #808148 - CVE-2012-1585 openstack-nova: Long server names grow nova-api log files significantly [epel-6] https://bugzilla.redhat.com/show_bug.cgi?id=808148 -------------------------------------------------------------------------------- ================================================================================ python-eventlet-0.9.16-5.el6 (FEDORA-EPEL-2012-0932) Highly concurrent networking library -------------------------------------------------------------------------------- Update Information: Fixes resource leak -------------------------------------------------------------------------------- ChangeLog: * Tue Mar 27 2012 Pádraig Brady <P(a)draigBrady.com - 0.9.16-5 - Update patch to avoid leak of _DummyThread objects * Wed Feb 29 2012 Pádraig Brady <P(a)draigBrady.com - 0.9.16-4 - Apply a patch to avoid leak of _DummyThread objects -------------------------------------------------------------------------------- ================================================================================ python-keystoneclient-2012.1-0.5.e4.el6 (FEDORA-EPEL-2012-0918) Python API and CLI for OpenStack Keystone -------------------------------------------------------------------------------- Update Information: This is required by the recent essex update for openstack-keystone (specifically the openstack-keystone-sample-data script) -------------------------------------------------------------------------------- ================================================================================ python-requests-0.10.6-3.el6 (FEDORA-EPEL-2012-0919) HTTP library, written in Python, for human beings -------------------------------------------------------------------------------- Update Information: python-requests on EPEL6 -------------------------------------------------------------------------------- References: [ 1 ] Bug #730570 - Review Request: python-requests - Python HTTP library for Humans https://bugzilla.redhat.com/show_bug.cgi?id=730570 -------------------------------------------------------------------------------- ================================================================================ relevation-1.1-3.el6 (FEDORA-EPEL-2012-0924) Command-line search for Revelation Password Manager files -------------------------------------------------------------------------------- Update Information: Fix missing package requirement, which could result in the program failing to run. Initial Fedora package release. Initial Fedora package release. Initial Fedora package release. -------------------------------------------------------------------------------- References: [ 1 ] Bug #807335 - relevation requires python-lxml ??? https://bugzilla.redhat.com/show_bug.cgi?id=807335 -------------------------------------------------------------------------------- ================================================================================ rubygem-dynect_rest-0.4.1-1.el6 (FEDORA-EPEL-2012-0935) Dynect REST API library -------------------------------------------------------------------------------- Update Information: Upstream update to 0.4.1 -------------------------------------------------------------------------------- ChangeLog: * Thu Mar 29 2012 Russell Harrison <rharriso(a)redhat.com> 0.4.1-1 - Update to 0.4.1 -------------------------------------------------------------------------------- References: [ 1 ] Bug #808020 - rubygem-dynect_rest-0.4.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=808020 -------------------------------------------------------------------------------- ================================================================================ trytond-1.8.6-1.el6 (FEDORA-EPEL-2012-0921) Server for the Tryton application framework -------------------------------------------------------------------------------- Update Information: update for CVE-2012-0215 -------------------------------------------------------------------------------- ChangeLog: * Fri Mar 30 2012 Dan Horák <dan(a)danny.cz> - 1.8.6-1 - new upstream version 1.8.6 (CVE-2012-0215) --------------------------------------------------------------------------------

12 years, 2 months

lessons to be learned from centos cloud image process?

by Matthew Miller

Take a look at this, and particularly the "kickstart git > image generation -> smoketest" workflow. ----- Forwarded message from Karanbir Singh <mail-lists(a)karan.org> ----- > Date: Sun, 26 Jan 2014 21:36:53 +0000 > From: Karanbir Singh <mail-lists(a)karan.org> > To: centos-devel(a)centos.org > Subject: [CentOS-devel] Cloud Instance SIG Hackathon @ CentOS Dojo 31st Jan > 2014 > > hi, > > We are organising a hack session to try and build, test and deliver a > set of CentOS-5/6 32bit/64bit images usable by various onpremise cloud > setups. This email aims to give everyone an overview of what to expect > on the day, so we can jump right in on the day and get productive. This > is a bit of a wordy email, so feel free to skip details - I will have > most of the important stuff on paper to hand out on the day as well. > > The Hack session is expected to start just after lunch, and will run > through to the end of the day ( ~ 17:30 ); > > On the day, I will have a local Wifi network with SSID DojoHackathon > running at the time, everyone wanting to participate will need to get > onto that. dhcp on the network will hand out 172.30.30.100 - 250 IP's. > There is a gateway on .1 that will NAT requests to the upstream internet > ( but I'm told its slow, so dont rely on it being there ). If anyone > needs content to pull, please let either me or Johnny know, we will > mirror it down before the event and make sure its on the mirror host on > the network at the time. We are going to have : > - CentOS 5/6 on both 32/64 bit x86 > - EPEL 5/6 > - EPEL-Testing 5/6 > > Various people representing projects have offered to bring pre-setup > cloud infra on their laptops, thanks for that. Lets try and target > everyone of those on the day. So far the list is : > - OpenNebula > - CloudStack > - OpenStack ( the HPCloud edition ) > - OpenStack ( the RDO edition ) > > A rather basic idea of what to expect in terms of infra/network on the > day : http://bit.ly/1ffXr4G ; Workflow anticipated: > > - git.centos.org ( hosted locally ) will have the git repos that host > kickstarts and metadata files that have some info around the kickstarts. > > - anyone can clone the git repos ( I will make sure its pretty clear as > to what repo to get for what task, ideally there will only be one git > repo with all the kickstarts ). > > - make changes / edits / push back to git.centos.org ( please ensure git > user.name and user.email is sane ) > > - git post-recv triggers kick off the actual image builds on the > image-builder node, which will then push the resulting file to > cloud.centos.org ( both image-builder and cloud.centos.org mirrors will > be hosted locally ). > > - cloud images from cloud.centos.org can then be downloaded and > instantiated on the cloud infra people are running; > > - once satisfied that the image does everything that is 'required', git > clone the t_functional repo, and run the test suite. PASS on that would > indicate them that the image is good to ship. For the day, we will trim > the test suite down to just the basic stuff that runs in 10 min or less. > > - Indicate pass with a comment in the metadata file and git commit which > starts with 'RELEASEABLE ', git push. > > rinse & repeat for 32bit and 64bit. > > Worth noting here that the reason i have all the various components > setup to work with real world urls ( faked by dnsmasq on the .1 machine > ) is that post hackathon the exact same infra will go live on the same > urls. With one major change : we will have little or no ACL's fon the > git repos at the hackathon to make live easier and encourage > participation. Post Hackathon, we'll need to establish a mechanism for > people to request commit access. > > If we still have time at the end of the day, we can shoot to deliver > something that works for vmware, ovirt and docker. I am still waiting to > hear back from the Eucalyptus guys if someone from their side is going > to be at the hack session. > > please note: all kickstarst and images will need to only consume content > hosted in mirror.centos.org and epel ( or if you need something else, > let us know before Wed 29th ). > > See you there, > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > _______________________________________________ > CentOS-devel mailing list > CentOS-devel(a)centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > ----- End forwarded message ----- -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>

10 years, 5 months

Re: F21 System Wide Change: Default Local DNS Resolver

by Jaroslav Reznik

----- Original Message ----- > = Proposed System Wide Change: Default Local DNS Resolver = > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > Change owner(s): P J P <pjp(a)fedoraproject.org>, Pavel Šimerda > <pavlix(a)pavlix.net>, Tomas Hozza <thozza(a)redhat.com> Ops, I was just pinged by Pavlix that the team planned this Change for F22 time- frame but I still live in the flood of F21 Changes and missed it. So the current state is - this Change targets Fedora 22 but most of the development should land into Fedora 21 - not enabled by default - to get test coverage. To make sure this Change is in the state it could be shipped in the release as default, corner cases has to be identified and worked on, there's also NetworkManager integration that has to happen. I'm sorry for confusion. Jaroslav > To install a local DNS resolver trusted for the DNSSEC validation running on > 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. > > The automatic name server entries received via dhcp/vpn/wireless > configurations should be stored separately, as transitory name servers to be > used by the trusted local resolver. In all cases, DNSSEC validation will be > done locally. > > This change was submitted after the Submission deadline. > > == Detailed Description == > There are growing instances of discussions and debates about the need for a > trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are > multiple reasons for having such a resolver, importantly security & > usability. > Security & protection of user's privacy becomes paramount with the backdrop > of > the increasingly snooping governments and service providers world wide. > > People use Fedora on portable/mobile devices which are connected to diverse > networks as and when required. The automatic DNS configurations provided by > these networks are never trustworthy for DNSSEC validation. As currently > there > is no way to establish such trust. > > 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]) > > Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, > having a trusted local DNS resolver will not only be imperative but be > unavoidable. Because it will perform the most important operation of > establishing trust between two parties. > > All DNS literature strongly recommends it. And amongst all discussions and > debates about issues involved in establishing such trust, it is unanimously > agreed upon and accepted that having a trusted local DNS resolver is the best > solution possible. It'll simplify and facilitate lot of other design > decisions > and application development in future. (See: [1], [2], [3]) > > People:- > * Petr Spacek > * Paul Wouters > * Simo Sorce > * Dmitri Pal > * Carlos O'Donell > > == Scope == > * Proposal owners: Proposal owners shall have to > ** define the syntax and semantics for new configuration parameters/files. > ** persuade and coordinate with the other package owners to incorporate new > changes/workflow in their applications. > > * Other developers: (especially NetworkManager and the likes) > ** would have to implement the new features/workflow for their applications > adhering to the new configurations and assuming the availability of the > '''trusted''' local DNS resolver. > ** NetworkManager already has features & capability to support local DNS > resolvers. Though few details are still under development, but are expected > to > realize in near future. Please see [4] > > * Release engineering: > ** would have to ensure that trusted local DNS resolver is available > throughout the installation stage and the same is installed on all > installations including LiveCDs etc. > > * Policies and guidelines: > ** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) > would have to ensure that their DNS resolver starts at boot time and works > out > of the box without any user intervention. > ** NetworkManager and others would have to be told to not tamper with the > local nameserver entries in '/etc/resolv.conf' and save the dynamic > nameserver > entries in a separate configuration file. > > [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html > [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html > [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html > [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html > > _______________________________________________ > devel-announce mailing list > devel-announce(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel-announce

10 years, 1 month

Re: default local DNS caching name server

by Paul Wouters

On Tue, 15 Apr 2014, William Brown wrote: >>> How do you setup DNS over TLS? >> >> Unbound has this capability already build in. unbound-control activates >> via (currently via dnssec-triggerd, in the future via NM) using the >> keywords tcp-upstream or ssl-upstream. > > I meant for say bind, but okay. bind does not support this. >> For a detailed list you will have to check the source code. But it >> includes thing like DNSSEC records, proper wildcard NSEC(3) records, >> CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older >> versions of common DNS software. Cases the IETF actually experienced in >> the wild. > > IE, If I have an out of box bind9 setup with a few zones, or even 100s > of zones, these cases should never be triggered. I would hate to see the > "dodgy DNS" check giving a false positive on networks that are actually > sane ... Such checks need to be conservative in their triggers IMO. Correct. It only happens for bind4/bind8 or broken old bind9s, djbdns/cache, but mostly because of 5 year old dnsmasq versions embedded in the platforms as "dns proxy". > Even if we ignore the TTL mangling, the first issue of incorrect cached > zone data moving between networks is a real world issue IMO. As > previously mention, split view business networks. I believe you have > said this is solved by flushing "." forwarder between networks that are > "secure". Correct. If an ISP starts modifying DNS content, it is simply an attack. You have no trust relationship with them. > The reason I ask these are documented, is so that when other network > admins (like myself) come along, you have already had the argument and > provided the justification and detailed explanations of these "edge > cases". Understood. >>> "suboptimal route". Your workaround will actually be detrimental to the >>> user experience. >>> >>> Note, I'm trying to optimise that path too, see: >>> http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-00 > > > These two statements really seem to contradict. On one hand you say that > moving between secure networks, the "." forwarder gets flushed. But then > you say the whole point is that it isn't flushed! The number of flushes should be limited as much as possible. It is only to accomdate certain networks that we flush the cache. Our preference is to never flush. But we accept sometimes it cannot be avoided to support certain type of DNS deployments. > On my 3g tether, and work, both would be secure wifi, so according to > this both flush (Which really, I like :) ) But according to what you are > saying they shouldn't do that, but they do? The price we have to pay to support some kind of setups. We can also add an option that tells us to not flush certain (secure) networks because we know there is no special casing there. Those are tunings we can do later. > Really, it seems like the only time the cache *won't* flush is when I > move from a secure wifi to an insecure wifi. What happens when I move > from the insecure wifi back? I would like to argue that given not all > domains have DNSSEC yet, you can't "trust" the records from the insecure > wifi, so at the least on insecure wifi interface down, you should flush > the non-dnssec cached records. Whether the network is "secure" or "insecure" only has an effect on the forwarder state, and thus potentially certain domains handled by that forwarder. DNSSEC validation is not skipped in those cases, so data can still be trusted. Non-DNSSEC domains are always vulnerable to a MITM. Since they can just sign their domains, I don't feel personally that we need to go out of our ways to accomodate those insecure setups. If people will differently, again we could tune and make a toggle. > Which collecting this seems to mean (Current functional state): > > Secure to secure network -> Flush "." cache. > Secure to insecure network -> Keep cache > Insecure to Insecure network -> Keep cache > Insecure to secure network -> Keep cache. > > I think in the perfect world, assuming that insecure networks are > insecure shouldn't it be? > > Secure to secure network -> Flush "." cache. > Secure to insecure network -> Keep cache > Insecure to insecure network -> Keep DNSSEC cache only. > Insecure to secure network -> Keep DNSSEC cache only. I'll think about these a little more. Note that "keep DNSSEC cache only" is currently not an option implemented by unbound. > The only records you can really guarantee as being the same on all > network views are ones signed by DNSSEC. Not really, you can have differently signed zones for the same name for internal and external view. Hopefully with at least the same DNSKEY, but even that could be different. It would require a manual configuration though of files in /etc/unbound/*.d/ Paul

10 years, 2 months

Re: [RFC] plans for initscripts in F22

by Reindl Harald

Am 26.04.2014 11:24, schrieb Michael Scherer: > Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : >> And it's not only commercial software; private projects that make no >> sense to publish (such as a company's web site) are equally affected >> such changes. Simply spoken, if we care only about package in Fedora, >> we are building an appliance; if we want to build an operating system, >> we do need to cater for software not included directly in the repo. > > Then how can we signal to people that they need to update those > packages ? the problem is that people don't want to rewrite/update perfectly working things which are broken by intention moving config files around or replace them with a completly new syntax because the rewrite of whatever piece of software did not have backwards compatibility in mind is annoying for a lot of reasons - besides some voices saying "i don't care about anything which is not part of the distribution" * it breaks working setups * it renders howtos invalid * it throws away knowledge of people that learned how to do things it's already a big problem that if you try to achieve something you can't rely on any information you find in the internet if it's not brand new written with stable interfaces and configurations you can build on top of several articles and howtos pieces together for your solution by permenantly changing interfaces (CLI params are user-interfaces) that ends in 3 of 5 pieces are still working that way but the big picture fails by the 2 no longer behave that way parts and if you try something you did never before and not sure what is the best way at all it get's really hard ________________________________________________________ i have built a lot of automation for systems administration that way over years where machines for different services are configuring themself by meta-informations coming from simple actions like "fill out one webform for a new domain" * register that domain via EPP * add the domain to the DNS servers * add the domain on the primary webserver and create a document root * create a mysql database * install our self written cms with a default setup and configure it for that database * add the domain including whois-infos to the billing database * add the email addresses to dbmail * add the domain * add the domain to the spamfirewall-appliance * add a SPF record to 4 nameservers with LAN/WAN DNS views * configure autoconfig/autodiscover aliases on apache and add the DNS records * add the domain on the Trafficserver machine (ATS and local dnsmasq) to later decide with a single DNS change if it needs load-balancing that can be one big task and several cronjobs on several machines are doing that one time, but all these jobs also working alone for cases where no mail addresses where ordered and 6 months later are needed - well, enter the mail-addresses in a textfield, the above tasks which are relevant are happening and the result is a list with username:generated-password so all that pieces are running standalone but also heavily combined if one of them falls because a change in the distribution the damage depends on which one, can it be automatically detected and following actions stopped while raise alarm, how can you test the cases which may lead to failing one of the pieces, how do you manage to test the behvior if the underlying operating system make abusive changes and last but not least even if you know which things are changing in case of dist-upgrades how do you plan these changes in case we are talking about a lot of machines acting together since a distupgrade on a ton of machines is a non-atmoic process and you hardly can stop the whole infrastruture until now i managed to surivive dist-upgrades from Fedora 9 to 19 in such a environment inluding make space for GRUB2 with test-machines and dd-dumps of the (luckily) /boot-disks instead partitions distributed but that don't mean you ask yourself not if the current change is really worth the impact ________________________________________________________ if you managed to get your result after that and the next Fedora version breaks it again because someone says "ah that was a terrible way to do things, we no longer support that please change that" and that happens too often it raises the question "is Fedora something you can build things on top of which is the job of an operating system or is Fedora something narcissistic you should avoid if you don't want to rebuild your work every few years or sometimes months" don't get me wrong, i am a perfectionist too re-factoring and optimizing my code up to comments and seek even wrong code-indenting of single lines while trying to get rid of code better never written that way - but doing that you need to draw a line where you better should stop because the damage defeats the positive effect and if you are not drawing that line you end in a loop of breaking, replacing, adopting, breaking, replacing, adopting simply because the now perfect thing 3 days later likely looks like "oh i would have better done this and that completly different" that's fine if it happens under stable interfaces but not if it demands the userbase to change their software running on top of yours > Because we can as well say "we are gonna support that forever", but that > will result into bitrot if no one really test. in case of network.service you have enough users which are testing and if it would have a problem in Rawhide make notice about

10 years, 2 months

Re: Local DNSSEC resolver and Docker(containers)

by Matt Micene

This gets worse when you add an overlay network provider, like flannel in Atomic, which provides a tunneled or encapsulated network to Docker containers that isn't accessible from the host. One of the on list responses talks about setting up a known IP space, taking a page from MS and using a local collision domain. AWS does this currently, making a metadata service available from all instances on 169.254.169.254. This could be a solution for a Docker environment, where a host provides the trusted DNSSEC enabled resolver on known single and unchanging IP address. This avoids the special nature of the loopback address, but gives consistency for a number of different approaches. -Matt M On Thu, Jan 15, 2015 at 9:17 AM, Daniel P. Berrange <berrange(a)redhat.com> wrote: > On Thu, Jan 15, 2015 at 01:57:59PM +0000, P J P wrote: > > Hello all, > > > > Please see: > > -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > -> https://pjps.wordpress.com/2014/05/02/local-dns-resolver-in-fedora/ > > > > > > This is an upcoming F22 feature; it proposes to install a local DNSSEC > > > > validating DNS resolver running at 127.0.0.1:53 on Fedora systems. This > > feature is already available in F21. One can easily run the local DNSSEC > > enabled resolver by > > > > $ sudo yum install dnssec-trigger > > > > $ sudo systemctl enable dnssec-triggerd.service > > $ > > $ # disable and stop any existing DNS service, e.g., dnsmasq > > $ sudo systemctl start dnssec-triggerd.service > > > > Though it works for most of the use-cases. Docker(or container) > applications > > seem to face problems in accessing the host's DNS resolver at > 127.0.0.1:53. > > > > I'm no expert on Docker(or container) applications. I was wondering if > someone > > could help in testing Docker(or container) applications with the local > DNSSEC > > validating resolver on F21. > > > > Any results from this exercise would be immensely helpful in fixing bugs > and > > sorting out edge cases, thus making the solution robust and ready for > F22 release. > > > > I'm willing to help in any way I could. As always, your comments and > suggestions > > are most welcome! > > NB this won't just be a Docker problem. It has the potential to affect any > container technology. eg a simple libvirt LXC container can be setup > sharing > the filesystem namespace, but with separate network namespace and so no > longer > have access to the same 127.0.0.1:53 binding. And libvirt-sandbox can > setup > KVM guests where the guest runs off a readonly passthrough of the host's / > but obviously the KVM guest will not see any host network interface. > > I think that probably the solution will have to involve any such apps doing > a bind mount on /etc/resolv.conf to reply the file with alternative content > Historically they tried to avoid that because doing a bind mount onto > /etc/resolv.conf would prevent the host OS from unlinking/replacing that > file. With this dnssec change though, /etc/resolv.conf will never get its > content changed once the OS is booted, so this bind mount problem would > no longer be an issue. > > An alternative would be for the container technology to setup some kind > of port forward, so that 127.0.0.1:53 inside the container get magically > forwarded to 127.0.0.1:53 outside the container. > > A slightly off the wall idea would be for the resolv.conf to not mention > 127.0.0.1:53 at all, and instead listen for DNS requests on a UNIX socket > in the filesystem. eg have resolv.conf refer to "/var/run/resolv.sock". > A container starting a new network namespace, but sharing the mount > namespace could still access that UNIX socket. If they had a private > mount namespace, they could bind mount the UNIX socket in. The big problem > is that while you could probably update glibc easily enough, there are > probably a fair few apps that directly parse /etc/resolv.conf and would > almost certainly get confused by a UNIX domain socket. So this idea would > probably not fly. > > Unless perhaps glibc could just try /var/run/resolv.sock unconditionally > and only if that's missing, then fallback to /etc/resolv.conf which would > contain 127.0.0.1:53 still. That way most apps would jsut work with the > UNIX socket and resolv.conf would still have a TCP socket for those which > need it. > > All the solutions need some work - I can't see any obvious way of making > the containers problem you describe "just work" without the developers > of such software doing some work. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ > :| > |: http://libvirt.org -o- http://virt-manager.org > :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > :| > _______________________________________________ > cloud mailing list > cloud(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >

9 years, 5 months

Search results for query "dnsmasq"