----- Original Message -----
> From: "Nick Jones" <nick.fa.jones(a)gmail.com>
> In the summary of this Fedora feature for fixing name resolution is
> this snippet: "Fedora could be seen as the leader in linux networking"
Yep. My intention to improve the overall networking features is not limited to what is described in FixNetworkNameResolution.
> getaddrinfo is important for Linux systems, and the existing issues
> with it's implementation are well worth fixing, but when it comes to
> DNS, getaddrinfo is holding Fedora and Linux back.
When it comes to DNS, it's absolutely necessary to run a local resolver like dnsmasq or unbound (the latter supporting DNSSEC) to achieve some of the advanced features like split lists of DNS name servers (e.g. for VPNs). But at least dnsmasq is already supported by NetworkManager.
> Even though DNS is not the only source of 'names' that getaddrinfo
> can return, it is the most important, and in the context of DNS,
> getaddrinfo will not let Fedora reach the above stated goal.
I'd be happy to discuss the details, probably in a separate discussion from this feature. Maybe IRC some time?
> It's not just the lack of support for asynchronous usage, getaddrinfo
> is a very feature poor resolver:
> - No support for alternative DNS record types: mx, txt ((ab)used for
> a lot of things)
True enough. I was thinking about implementing at least SRV records.
> - No support for DNSSEC
True enough. And also no support for DNS lifetimes. There probably should be a more coprehensive API for that while getaddrinfo would work on top of it.
> - No TCP fallback for that matter, which is essential for the above
This should be handled in the DNS daemon (or supplementary tools) anyway.
> - Probably lot more, I'm no expert on dns
Possibly.
> What is needed for networking leadership is:
> - a feature rich resolver, supporting the above as well as query
> and response filtering, ala AI_ADDRCONF
Agreed.
> - an implementation of an IPv6 migration strategy along the lines
> of Happy Eyeballs
I'm afraid this is not limited to DNS.
> - can be used both asynchronously or synchronously
That would be nice. Communication with a daemon over sockets works asynchronously for free.
> - ideally pulls in no dependencies outside libc, except perhaps
> libidn
That would require a custom communication protocol for the async part.
> - ideally the DNS packet parsing routines use only ANSI C
> - can be used by both C and C++ applications, and is easily
> bound to other scripting languages, even in the async case
That again suggests a daemon with IPC.
> - provides reverse lookup
Sure.
> - more I can't think of right now but I hope others will add more
It would be better to maintain such information on a wiki page or something. Nobody will come back to the e-mails now and then.
> The question is does this all get added into glibc?
> 1) Yes:
> - glibc getaddrinfo gets updated to support this through
> the addition of new hints flags and return values, or a new
> function interface is created instead of shoehorning into the
> old interface, in any case the old getaddrinfo interface will
> always be callable using traditional, existing semantics and
> run time linking to existing apps will not be broken
> - the nss layer gets rewritten to support asynchronous usage
> (and decent error reporting and additional lookup domains
> maybe samba?)
> - perhaps the resulting work gets packaged into a proposed
> extension to POSIX
Even if this could be done, it looks like a very-long-term project and needs more than just dropping suggestions to a mailing list.
> 2) No:
> - simply say: forget it, lets do proper DNS outside of libc
We already can do proper DNS outside libc. There's no problem with that. The more complicated part is getting all sorts of resolution methods together.
> I say 1) could be possible over the course of a few years but
> for now, 2) is more realistic.
>
> As a quick summary: I would suggest, in addition to addressing
> the outstanding bugs and issues covered by the Fedora feature,
> a flag be added to the set of getaddrinfo parameters that
> instructs it NOT to do DNS lookups, only perform alternative
> resource lookups supported by nss. This flag would be something
> like: AI_NODNS
I'm not in favor of adding this flag, as DNS is not IMO as specific.
> This will allow application developers to make use of
> getaddrinfo for resolving names using non dns sources
What for?
> (hosts file is DNS,
This is a huge mistake. Many of the bugs are results of treating the /etc/hosts the same way as DNS resolution. While the /etc/hosts file often overrides the information that would otherwise be recieved through DNS, it is no DNS at all, just a way to specify static mapping between names and addresses.
> so this means ldap and others), then perform
> internet domain lookups using an alternative DNS library that
> is standardised in Fedora.
I don't think this is a good solution.
> Given that in most systems, the nss alternatives are local file
> based,
Not at all. And even less in the future.
> and given the option of using nsscache, these lookups
> could be considered reasonably constrained therefore NOT in
> need of asynchronous implementations.
>
> Over time, the alternative DNS library could be considered for
> inclusion in the core c library, and could replace the DNS
> lookup aspect of getaddrinfo, at least for A and AAAA lookups,
> and more if additional query flags are defined for getaddrinfo
> or if an alternative function interface is defined.
Spliting out DNS from other host name resolution more than it is now, would IMO be a huge mistake. There's not just DNS out there.
> In addition, work can be done to make the nss layer
> asynchronous, or at least constrain it to local file resources and
> standardise on the use of nsscache.
This is something that could be discussed after fixing up the current synchronous API.
> Or use this effort to re implement a switched name service
> lookup library, including DNS aspect, outside of glibc.
Also worth discussing later.
Cheers,
Pavel
On Tue, 22.02.11 14:51, Josef Bacik (josef(a)toxicpanda.com) wrote:
> Hello,
>
> So we're getting close to having a working fsck tool so I wanted to
> take the opportunity to talk about the future of BTRFS in Fedora.
> Coming up in F15 we're going to have the first release of Fedora where
> we don't need the special boot option to have the ability to format
> you filesystem as BTRFS. This is in hopes that we can open it up for
> wider testing before possibly making it the default filesystem. I
> realize we're in the early stages of F15, but since filesystems are
> big and important I'd like to get an idea of the amount of work that
> needs to still be done to get BTRFS in shape for being Fedora's
> default filesystem. So here are my goals
>
> 1) Fedora 16 ships with BTRFS as the default root filesystem.
Hmm, what are your plans regarding hierarchy layout for this?
My hope is that one day we can ship a read-only root dir by default, or
more specifically a btrfs file system with three subvolumes in it: one
read-only one mounted to /, and two writable ones mounted to /home and
/var, with /tmp mounted from tmpfs.
We came a long way with supporting read-only root dirs and it should
mostly work now. In F15 for example /etc/mtab is a symlink, and even
smaller stuff like /etc/nologin got moved to /var/run, to make write
accesses to /etc unnecessary during normal operation. /etc/resolv.conf
is the only thing often updated that's left, but with NM using dnsmasq
it's static too.
By using btrfs subvolumes doing this kind of seperation into writable
and non-writable subtrees we don't have to think anymore about the sizes
for those file systems at install time, since they all live in the same
fs.
If this is adopted package managers and system configuration UIs would
need to invoke "mount / -o rw,remount" before doing their work.
So, I'd like to see this implemented one day, maybe the adoption of
btrfs is the right time to push this through too?
I have not filed a feature page for this, as I am not sure I want to
push this on F16, and I don't even know if people in general are onboard
with this idea. The benefits of this are mostly security and robustness
since we know that the actual subvolume the OS is booted from is always
in a consistent state during operation and cannot normally be
changed. And of course, we get all kind of magic by doing this because
we can easily use snapshots to roll back system upgrades while leaving
/home completely untouched.
Sorry for hijacking your thread like this,
Lennart
--
Lennart Poettering - Red Hat, Inc.
Am 13.04.2014 08:42, schrieb Simo Sorce:
>>>> * DNS cache should be flushed on route or interface state change.
>
> I do not see why, the only reason to flush a cache is when there is a
> DNS change (new interface, eg VPN coming up, or going away)
because if i change my routing from ISP to VPN i want to access
the company severs over the VPN - any of them
changing the default root is a common way for such a switch
>> the cache already is running in my LAN for good reasons
>
> That's a different cache, however if you feel strongly you will be able
> to turn off the local caching dns server on your machines, at your
> option.
>
>> that DNS cache is pushed with DHCP
>
> Forwarders are pushed via DHCP, not caches
says who?
you or better the one built the network and services?
the via DHCP pushed DNS servers are caches because they do not forward
anything, they are doing recursion - if youre DNS servers are only
forwarders consider to change that
frankly the main reason i stepped in that thread at all is that
people started to talk about recursion / forwarding without
understand that both terms in case of DNS
>> that DNS cache already does DNSSEC validation
>
> Which is useless in the *general* case. You may think your physical
> security is perfect, that;s great, but for everybody else, trusting the
> network is not ok, that's why more an more people de[ploy TLS or GSSAPI
> in internal networks too.
> The era of the clear text trusted private network is coming to an end,
> whether you like it or not.
>
>> if you don't trust the network itself you are lost anyways
>
> Let me troll a bit, this is why you do all your banking without
> HTTPS ? :-)
that is a completly different story, you enter a HTTPS URL manually
or triggered by HSTS, so you request a encrypted connection from
the very first start
in case of DNS there is nothing encrypted at start resolving
and if i proper manipulate the network you are in i hide any
DNSSEC response from you (deep packet inspection)
> I am strongly in favor of a DNS cache on Fedora, and I would even
> seriously consider any proposal of making it the default on Fedora
> Server too
as long as it is not a hard wired dependency.....
i don't need additional DNS servers on any system
the systems are running BIND are doing that with good reasons
the systems running Unbound as local cache doing that for good reasons (MTA servers)
the systems running dnsmasq are doing it for good reasons (Reverse-proxy with own DNS view)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote:
> You can find source and package pre-releases at:
> ftp://ftp.xelerance.com/dnssec-trigger/
At least for Fedora 15:
BuildRequires: glib-devel, gtk2-devel, ldns-devel
and in %install
mkdir -p %{buildroot}%{_localstatedir}/run/dnssec-triggerd
After killing off dnsmasq and starting unbound and dnssec-trigger,
Sep 17 18:19:02 laptop setroubleshoot: SELinux is preventing
/usr/sbin/unbound from name_bind access on the tcp_socket port 8953. For
complete SELinux messages. run sealert -l 924dfa70-fe9e-4cc0-add0-
364b8ae90ef6
grep unbound /var/log/audit/audit.log | audit2allow -M unboundpatch
semodule -i unboundpatch.pp
cat /etc/resolv.conf
# Generated by dnssec-trigger 0.3
nameserver 127.0.0.1
It took over dns via unbound, even though the dhcp assigned dns servers
allow dnssec queries.
dnssec-trigger-control-setup
setup in directory /etc
dnssec_trigger_server.key exists
dnssec_trigger_control.key exists
create dnssec_trigger_server.pem (self signed certificate)
create dnssec_trigger_control.pem (signed client certificate)
Signature ok
subject=/CN=dnssec-trigger-control
Getting CA Private Key
Setup success. Certificates created.
dnssec-trigger-control-setup -i
setup in directory /etc
unbound-checkconf: no errors in /etc/unbound/unbound.conf
checking if unbound-control needs to be enabled
checking if root trust anchor needs to be enabled
fetching or updating root trust anchor: unbound-anchor
[1316311135] libunbound[17598:0] error: ldns error while converting
string to RR: Syntax error, could not parse the RR's rdata
[1316311135] libunbound[17598:0] error: failed to load trust anchor from
/etc/unbound/root.key at line 2, skipping
[1316311135] libunbound[17598:0] error: ldns error while converting
string to RR: Syntax error, could not parse the RR's TTL
[1316311135] libunbound[17598:0] error: failed to load trust anchor from
/etc/unbound/root.key at line 4, skipping
[1316311135] libunbound[17598:0] error: failed to read
/etc/unbound/root.key
[1316311135] libunbound[17598:0] error: error reading auto-trust-anchor-
file: /etc/unbound/root.key
[1316311135] libunbound[17598:0] error: validator: error in trustanchors
config
[1316311135] libunbound[17598:0] error: validator: could not apply
configuration settings.
[1316311135] libunbound[17598:0] error: module init for module validator
failed
add to /etc/unbound/unbound.conf: auto-trust-anchor-file:
"/etc/unbound/root.key"
check for search path in resolv.conf and edit /etc/dnssec-trigger.conf
check for domain in resolv.conf and edit /etc/dnssec-trigger.conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFOdVItL6j7milTFsERAjHqAKCDFvKuwgKiYvRtvJBUVRpunvAxmQCbBVJP
lsJmLAFHfCBnFPrR4/exxME=
=KN8D
-----END PGP SIGNATURE-----
On 11/18/2012 10:57 AM, Nux! wrote:
> On 18.11.2012 08:16, Nux! wrote:
>> On 18.11.2012 05:42, Gary Kotton wrote:
>>> Hi Lucian,
>>
>> Hello Gary,
>>
>>>> 1. At the "Please check that the following are in
>>>> /etc/quantum/l3_agent.ini" section turns out that what I had in my
>>>> ini file was this:
>>>> "auth_url = http://127.0.0.1:5000/v2.0/
>>>> auth_region = RegionOne
>>>> admin_tenant_name = admin
>>>> admin_user = admin
>>>> admin_password = verybadpass"
>>>> I commented that out and replaced with the settings from instructions.
>>>
>>> Did you run the "sudo quantum-l3-setup --plugin openvswitch"?
>>
>> Yes!
>
> Right, this one I solved by replacing servicepass with verybadpass in
> /etc/quantum/l3_agent.ini; so the section looks like this (wiki page
> should be updated):
> auth_url = http://localhost:35357/v2.0/
> auth_region = RegionOne
> admin_tenant_name = service
> admin_user = quantum
> admin_password = verybadpass
>
>
>>
>>>>
>>>> All the quantum/openvswitch router/soubet/etc add worked
>>>> (surprisingly). But now I see the following errors:
>>>>
>>>> /var/log/quantum/l3-agent.log:
>>>> Unauthorized: {"error": {"message": "Invalid user / password",
>>>> "code": 401, "title": "Not Authorized"}}
>
> This went away, too, apparently after fixing the file with the right
> credentials.
>
>>>> Stderr: '\ndnsmasq: cannot run lease-init script
>>>> /usr/bin/quantum-dhcp-agent-dnsmasq-lease-update: No such file or
>>>> directory\n'
>
> This went away after `setenforce 0` so right now I'm running without
> selinux..
>
>
> I still could not launch an instance though, http://fpaste.org/rQcV/
> The workaround is to do this
> http://wiki.libvirt.org/page/Guest_won%27t_start_-_warning:_could_not_open_…
Are you using "libvirt_vif_driver =
nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver" in nova.conf?
>
> Is there any fix coming? Running with these settings really makes me
> uncomfortable.
>
>
>
>
Hello,
I ran a few scripts on the CVS tree and will commit the resulting improvements
in a few days to devel and rebuild changed packages if ACL's allow. Let me
know if you for some reason don't want your packages touched (affected package
lists below).
1) Convert remaining non-UTF-8 specfiles to UTF-8. This is a no-brainer.
2) A number of packages are not using the "best" _upstream_ (I'm not
repackaging anything) tarball available that we can use. Using the best
available one will result in smaller srpm sizes, less downloading from CVS
lookaside cache and upstreams etc. I'm defining goodness in descending order
as: xz, lzma, bz2, gz, zip, tar; and will compare tarball contents before
making any changes. Packages whose SourceX URLs are bad are almost certainly
missed in this batch. There are two scenarios where I'm going to make other
changes besides just change the tarball in order to keep it possible for
packagers to easily keep sharing specfiles between branches:
2a) If the tarball is going to be switched to an lzma one and the package has
an EL-5 branch that seems relatively up to date with the devel branch, I'll
add "BuildRequires: lzma" because while the EL-5 rpmbuild's %setup knows what
to do with lzma tarballs, it doesn't have a dependency on lzma.
2b) If the tarball would be switched to an xz one but the package has
relatively up to date F-10 or EL branches, I'm not going to switch the tarball
or build at all but will add a TODO comment to the specfile noting that such a
tarball would be available, because F-10 and EL rpmbuilds' %setup doesn't grok
xz tarballs.
Packages with non-UTF-8 specfiles:
----------------------------------
doxygen
enscript
fluxbox
fluxconf
GConf2
gnome-vfs2
intltool
irda-utils
jakarta-commons-digester
jlex
joystick
kdbg
lapack
libksba
librsvg2
logjam
mkinitrd
psgml
psutils
rarpd
sip
splint
switchdesk
system-config-kickstart
talk
velocity
werken-xpath
yp-tools
Packages that may have a better upstream tarball available:
-----------------------------------------------------------
(not necessarily all of these will be touched)
abcm2ps
anjuta
archimedes
autoconf
autogen
avr-gdb
bigboard
bluez
cflow
cluster-glue
CodeAnalyst-gui
compiz-manager
conduit
curl
cylindrix
deletemail
dnsmasq
doodle
dosfstools
eggdrop
emacs
epic
ewl
expect
fspy
gajim
gaupol
geany-plugins
gedit-plugins
gget
giggle
gnash
gnome-packagekit
gnome-power-manager
gnonlin
gnucash
gpm
gsh
gtk-vnc
hal
hatools
highlight
hotwire
hunspell-fo
icon-naming-utils
inkboy-fonts
irssi
jam
java-1.6.0-openjdk
kiosktool
KoboDeluxe
lftp
libcmpiutil
libgdbus
libgdl
libsexy
libtheora
libtool
libuninum
libzip
lzma
m4
maradns
mikmod
minbar
moserial
mpfr
msr-tools
netbeans-resolver
nfoview
notify-python
obexd
online-desktop
pacemaker
parted
perl-qooxdoo-compat
php-magickwand
pipenightdreams
pixman
ppl
proj
psad
python-kiwi
python-pp
qt-creator
redet
redet-doc
reiserfs-utils
resource-agents
rfdump
rxtx
sed
spamass-milter
spring
straw
subversion
surl
tango-icon-theme
teseq
texinfo
udpcast
ustr
warzone2100
ytalk
zenon
zlib
On Tue, Feb 22, 2011 at 5:07 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> On Tue, 22.02.11 14:51, Josef Bacik (josef(a)toxicpanda.com) wrote:
>
>> Hello,
>>
>> So we're getting close to having a working fsck tool so I wanted to
>> take the opportunity to talk about the future of BTRFS in Fedora.
>> Coming up in F15 we're going to have the first release of Fedora where
>> we don't need the special boot option to have the ability to format
>> you filesystem as BTRFS. This is in hopes that we can open it up for
>> wider testing before possibly making it the default filesystem. I
>> realize we're in the early stages of F15, but since filesystems are
>> big and important I'd like to get an idea of the amount of work that
>> needs to still be done to get BTRFS in shape for being Fedora's
>> default filesystem. So here are my goals
>>
>> 1) Fedora 16 ships with BTRFS as the default root filesystem.
>
> Hmm, what are your plans regarding hierarchy layout for this?
>
> My hope is that one day we can ship a read-only root dir by default, or
> more specifically a btrfs file system with three subvolumes in it: one
> read-only one mounted to /, and two writable ones mounted to /home and
> /var, with /tmp mounted from tmpfs.
>
Yeah the hope is to separate out various things into different
subvolumes so we can have things that can be independently
snapshottable things.
> We came a long way with supporting read-only root dirs and it should
> mostly work now. In F15 for example /etc/mtab is a symlink, and even
> smaller stuff like /etc/nologin got moved to /var/run, to make write
> accesses to /etc unnecessary during normal operation. /etc/resolv.conf
> is the only thing often updated that's left, but with NM using dnsmasq
> it's static too.
>
> By using btrfs subvolumes doing this kind of seperation into writable
> and non-writable subtrees we don't have to think anymore about the sizes
> for those file systems at install time, since they all live in the same
> fs.
>
> If this is adopted package managers and system configuration UIs would
> need to invoke "mount / -o rw,remount" before doing their work.
>
> So, I'd like to see this implemented one day, maybe the adoption of
> btrfs is the right time to push this through too?
>
> I have not filed a feature page for this, as I am not sure I want to
> push this on F16, and I don't even know if people in general are onboard
> with this idea. The benefits of this are mostly security and robustness
> since we know that the actual subvolume the OS is booted from is always
> in a consistent state during operation and cannot normally be
> changed. And of course, we get all kind of magic by doing this because
> we can easily use snapshots to roll back system upgrades while leaving
> /home completely untouched.
>
> Sorry for hijacking your thread like this,
>
It's cool, just hilights all the cool stuff we can do with BTRFS :). Thanks,
Josef
On Wed, Sep 14, 2011 at 10:25:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 14, 2011 at 02:25:52PM +0300, Pasi Kärkkäinen wrote:
> > On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote:
> > > Hi,
> >
> > Hello,
> >
> > > Virtualization Test day is expected to be on September 15th this year
> > > ([1]https://fedorahosted.org/fedora-qa/ticket/232).
>
> Cool.
> > >
> >
> > So that's tomorrow!
> >
> > Luckily Xen Hackathon (@Munich) event is just happening,
> > so hopefully we can get some more testing from people in that event.
> >
> > > We are willing to help test
> > > [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little
> > > information about test methods
>
> It really ought to be parallel to what you would do with KVM/QEMU. Basically
> the same steps - but I am not sure how well does libvirt work with xm/xl nowadays.
> Or the virt-manager - but it suppose to interact with magically.
>
libvirt support for xm/xend *should* work, and there's also the libvirt libxl driver
written by Jim Fehlig from Novell/SUSE.
> Is there a KVM/QEMU/libvirt help test Wiki? I saw this:
> https://fedoraproject.org/wiki/Getting_started_with_virtualization
> and it kind of parallels it, albeit I didn't see anything about setting the network
> which sometimes is the biggest pain point:
>
> http://www.fedoraforum.org/forum/showthread.php?t=268427
>
When you install libvirt it'll automatically create/start a bridge called "virbr0",
which is an host-internal bridge with "dnsmasq" running and configured to provide dhcp server
with private ip range, dns relay and NAT on that bridge.
So that's good enough for trying some VMs or running VM netboot installs.
>
> > > ([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.
>
>
> There are known bugs in FC15/FC16 that have been filled some time ago that
> folks will sadly run into: 728775, 658387 and 668063
>
> Fortunatly the bugs have patches attached and the files to be modified are shell scripts.
>
Yep, links here:
https://bugzilla.redhat.com/show_bug.cgi?id=728775https://bugzilla.redhat.com/show_bug.cgi?id=658387https://bugzilla.redhat.com/show_bug.cgi?id=668063
-- Pasi
> > > Regards,
> > >
> >
> > I just added some Xen related mailinglists to the CC list,
> > so we can get more feedback.
> >
> > Thanks,
> >
> > -- Pasi
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel(a)lists.xensource.com
> > http://lists.xensource.com/xen-devel
On Sat, 2008-03-08 at 00:36 -0600, Callum Lerwick wrote:
> On Wed, 2008-03-05 at 18:06 -0500, Dan Williams wrote:
> > The problem is that some people want DHCP on their WLAN adhoc
> > networks... I still need to figure out how the Apple connection sharing
> > works; they use IPv4 LL addresses in the created Ad-Hoc network but I
> > don't know how other machines get the default route to the one sharing
> > its connection. Possibly the router announces itself with Avahi or
> > something.
>
> The connection sharing box provides DHCP.
You are correct, I've verified this on 10.3 & 10.4. The Airport card
comes up in infrastructure mode, the bootpd process is running, and the
Airport card is assigned an address in the 10.x.x.x space. I'm not
entirely sure why I thought they did Ad-Hoc in the past, but it might
have been that the iBook I was using to connect to the G4 that was
sharing the connection failed to connect (wrong WEP key perhaps) and
just got an autoip address instead.
In any case, this is good for Linux as a client of Apple's ICS, because
it just works.
But it's bad for Linux as the software base station itself, because so
many of the current drivers just suck really really hard for
infrastructure mode. Beyond the hostap Prism 2/2.5/3 driver, I can't
think of a single driver that does master mode well at all, and even the
mac80211-based drivers, while they are quite capable of being APs, are
somewhat tied to the specific version of the hostapd since the interface
there is still evolving.
So for the time being, NetworkManager 0.7 will:
1) as the _originator_ of a wireless network, either by sharing a
connection or creating a new wireless network, use 802.11 Ad-Hoc and
provide a DHCP server (probably using dnsmasq)
2) require opt-in to get IPv4 LL on device types known to usually use
DHCP, requiring the user to pick between Auto-IP and DHCP (ie, Auto-IP
and DHCP will be mutually exclusive)
3) Perform DHCP by default on Ad-Hoc networks, unless the user has opted
into Auto-IP in the connection editor
Dan
> > There does need to be more thought here; but I'm leaning towards
> > defaulting connections created when the user explicitly shares an
> > existing connection (ie, you pick "Share this mobile broadband card over
> > wireless") to zeroconf. In the end there will still be booleans in the
> > config to mark DHCP yes/no and zeroconf yes/no. I'm wondering if the
> > zeroconf option should be mutually exclusive with any of the others; ie
> > would you ever want to have a secondary IPv4 LL address at the same time
> > as you have a non-LL address.
>
> Has ANYONE here actually read rfc3927? Link local means just that, link
> local. Read the second paragraph of the abstract, and section 2.7 and
> 2.8, titled "Link-Local Packets Are Not Forwarded" and "Link-Local
> Packets are Local".
>
> Therefore, any device providing routing of any kind, MUST use something
> else, namely DHCP.
>
> This shit should Just Work, the only UI there should be is a checkbox to
> disable "auto configuration" and set fixed settings.
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, Jul 13, 2010 at 04:00:12PM -0500, Connie Sieh wrote:
> I am trying to install koji-hub 1.4 on RHEL6 Beta 2. I obtained the rpm
> from EPEL. koji-hub requires mod_python but mod_python was removed from
> the RHEL6 Beta even though it is still in Fedora 13. I am assuming that
> mod_python was removed from RHEL6 Beta because mod_wsgi is to replace it.
> For my immediate testing needs I can find mod_python on the web.
>
> So the question is will koji be moving over to mod_wsgi or will RHEL 6
> include mod_python in the future.
Hello Connie Sieh,
koji-1.4 as released last weekend works pretty fine with the current
RHEL6-beta2. You can recompile mod_python from Fedora-rawhide to have it
up and running.
I've started a small collection of rpms for RHEL6 that I want to keep
more lined up to Fedora-devel here:
http://jur-linux.org/rpms/el-updates/6/
Some of the other updated or newly compiled rpms include:
- mailman-2.1.13
- newest dovecot-2.0
- rsync-3.0.7
- squid 3.1.4
- fail2ban
- bugzilla-3.6.1
- collectd-4.10.1
- git-1.7.1.1
- mercurial 1.5.4 and 1.6
- cfengine
- dnsmasq 2.52
- moin 1.88
- msmtp
Back to koji, the config is pretty much straight forward from the wiki pages:
name="rhel6"
koji add-tag dist-$name
koji add-tag --parent dist-$name --arches "i686 x86_64" dist-$name-build
koji add-external-repo -p 50 -t dist-$name-build dist-$name-external \
http://194.168.123.22/mirror/rhel6/5.90Server/\$arch/os
koji add-external-repo -p 51 -t dist-$name-build dist-$name-cs-external \
http://194.168.123.22/mirror/rhel6/5.90Server/\$arch/os/ClusteredStorage
koji add-external-repo -p 52 -t dist-$name-build dist-$name-ha-external \
http://194.168.123.22/mirror/rhel6/5.90Server/\$arch/os/HighAvailability
koji add-external-repo -p 53 -t dist-$name-build dist-$name-lb-external \
http://194.168.123.22/mirror/rhel6/5.90Server/\$arch/os/LoadBalance
koji add-external-repo -p 55 -t dist-$name-build dist-$name-optional \
http://194.168.123.22/mirror/rhel6/5.90Server/optional/\$arch/os
koji add-external-repo -p 60 -t dist-$name-build dist-$name-epel-external \
http://194.168.123.22/mirror/fedora-epel/beta/6/\$arch/
koji add-target dist-$name dist-$name-build
koji add-group dist-$name-build build
koji add-group-pkg dist-$name-build build \
bash bzip2 coreutils cpio diffutils findutils gawk gcc gcc-c++ grep gzip \
info make patch redhat-release-server redhat-rpm-config rpm-build sed \
shadow-utils tar unzip util-linux-ng which
koji add-group dist-$name-build srpm-build
koji add-group-pkg dist-$name-build srpm-build \
bash curl cvs gnupg make redhat-release-server redhat-rpm-config \
rpm-build shadow-utils
koji add-group dist-$name livecd-build
koji add-group-pkg dist-$name livecd-build \
bash bzip2 coreutils cpio diffutils findutils gawk gcc gcc-c++ grep gzip \
info make patch redhat-release-server redhat-rpm-config rpm-build sed \
shadow-utils tar unzip util-linux-ng which \
python-dbus yum squashfs-tools livecd-tools selinux-targeted-policy
regards,
Florian La Roche
