-----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-----
https://bugzilla.redhat.com/show_bug.cgi?id=1128208
Bug ID: 1128208
Summary: docker io not using proper DNS
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: briemers(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, dgoodwin(a)redhat.com,
eparis(a)redhat.com, extras-qa(a)fedoraproject.org,
gansalmon(a)Gmail.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, itamar(a)ispbrasil.com.br,
jeder(a)redhat.com, jonathan(a)jonmasters.org,
jpazdziora(a)redhat.com, jperrin(a)centos.org,
kernel-maint(a)redhat.com, lars(a)redhat.com,
lsm5(a)fedoraproject.org, madhu.chinakonda(a)gmail.com,
mattdm(a)redhat.com, mchehab(a)infradead.org,
mgoldman(a)redhat.com, pmoore(a)redhat.com,
rbriggs(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1119849
The resolution for Bug #1119849 introduced a new problem.
I have a dockerfile that uses the command:
git clone http://gitolite.corp.redhat.com/cgit/it-sales/sfjavasuite.git/
Up until the most recent update the dockerfile worked expected. Now it fails
with a hostname not found.
It seems part of the update is docker will now try and use fixed DNS values of
8.8.8.8 and 8.8.4.4. Which is of course in appropriate for anyone inside a
private network. In some cases it is even considered a security risk to have
DNS lookups leak to a public DNS server, as it gives outside user information
about the private network.
It is possible to update the docker options to work around the problem. But
of course the DNS servers obtained by DHCP, so it would require restarting
docker-io with new settings everytime a new network connection is
established...
Likewise another workaround is a set if iptable rules to override all DNS
lookups but again this introduces it's own set of problems.
And of course, I don't want to assume everyone who will use my Dockerfile has
updated their workstations and servers with whatever hack solution I use...
Reproduce steps:
1. docker run fedora cat /etc/resolv.conf
Expected results:
The DNS settings equivalent to the host, which in my case are:
$ cat /etc/resolv.conf
# Generated by NetworkManager
domain docbill.info
search docbill.info
nameserver 127.0.0.1
nameserver 172.31.253.1
nameserver 172.31.252.1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 10.11.255.155
nameserver 10.11.255.156
nameserver 10.5.26.21
nameserver 10.7.142.20
nameserver fe80::beae:c5ff:fee8:b5e%em1
nameserver fe80::4216:7eff:feea:a5b8%em1
nameserver 2001:470:1d:8a2::1
Actual results:
$ docker run fedora cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
search docbill.info
Note: I'm not sure how the previous docker-io version got the 127.0.0.1
correct. But somehow it figured out that was an instruction to use the dnsmasq
instance on my laptop.
Bill
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1119849
[Bug 1119849] su - postgres Results in System Error inside Fedora
20/rawhide containers
--
You are receiving this mail because:
You are on the CC list for the bug.
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,
Joerg Stephan píše v Pá 20. 11. 2009 v 19:37 +0100:
> Hello again,
>
> since i've posted (i know its not that long ago) i made several changes
> to the side
>
> https://fedoraproject.org/wiki/SIGs/Server/ServersOverview_alpha
>
> i think the Database section is a good layout for handling the stuff.
the new layout looks really better then my original, but I have few
items for discussion:
- the X/GUI column needs some explanation what it exactly means
- would be nice to have information about all live releases (like F11
and F12) and rawhide, probably by creating 3 sub-lines for every package
- column for notes, useful for example in dnsmasq - "only dbus-libs
required, dbus itself can be stopped"
Dan
> kind regards
> Jörg
>
> On Thu, 2009-11-19 at 18:11 +0100, Joerg Stephan wrote:
> > Hello all,
> >
> > my Name is Joerg Stephan and work as a Sysadmin at an Research Facility
> > in Germany. I'am using Linux since RedHat 5.1 after a virus crashed my
> > "other" OS. Maybe because of my work i'am interested in server systems,
> > so i thought it could be a good idea to join the ServerSIG.
> > On IRC you can find me in the #fedora-server channel as johe or johe|
> > work (depends on where i'am :-).
> >
> > So had a short conversation with sharkcz (Don i think) and he replaced
> > the Server_overview side so i could add packages to it. While taking a
> > look at the side i thought it would be a nice idea to change the
> > information on it a bit.
> >
> > Cause this seems to be a team sport i just made a side
> >
> > https://fedoraproject.org/wiki/SIGs/Server/ServersOverview_alpha
> >
> > to have a discussion on this issue. Maybe on this side there could be
> > spread a bit more information. Installing instructions, known and not
> > fixed bugs could be refered on this side.
> >
> > I'am currently settle up an virtual server at my home, so it should no
> > problem installing a fedora server and so updating the versions
> > displayed on the side.
> >
> > So let the discussion begin :-)
> >
> > regards
> >
> > Jörg
> >
> > _______________________________________________
> > fedora-server-list mailing list
> > fedora-server-list(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
>
>
> _______________________________________________
> fedora-server-list mailing list
> fedora-server-list(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
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
Jima wrote:
> Hi folks!
>
> As per the "Getting Started" walkthrough, I thought I'd spam you guys
> with a brief rundown of who I am, although I'm sure a number of you
> already know.
> My name is Patrick Laughton, although most people who know me call me
> Jima (yes, IRL, too). I hail from the Great White North --
> Minneapolis, MN, or thereabouts. (That's in the Central US time zone,
> CDT/GMT-5.) I've been maintaining Linux boxen for maybe ten years,
> seven of those professionally. I started out with Slackware (how's
> that for cutting your teeth?), but long ago moved to Red Hat, and then
> Fedora.
>
> Like many in Fedora Packager Land, I got started because as a
> sysadmin, there were often packages I needed that weren't otherwise
> easily available. So I packaged what I needed, threw them in a
> repository, and went on my merry way. What a pain.
> I joined Fedora Extras about 16 months ago to offset some of that
> heavy lifting. In addition to making sure everything I needed was in
> Fedora, I took on some orphaned packages, and generally looked for
> other ways I could help out the project. That's what brings me to
> Infrastructure; to see if any of my possibly mediocre skills as a
> sysadmin might in some way benefit the bigger picture.
>
> I'll be up-front: I'm not a programmer. I can't code worth crap. I
> know a little C (not C++), my perl talents are decent (if sloppy and
> roundabout), but I can shell script like mad.
> I'm fairly comfortable with Apache, BIND, dnsmasq, Exim, OpenSSH,
> Postfix, and Sendmail. Okay, if it's a daemon, I'm probably not too
> bad with it. I've played with Nagios and MRTG on and off over the
> years, as well. More recently (in the last year or so) I've gotten
> fairly good at working with Xen. Not KVM, sadly, due to my general
> lack of machines with hardware virtualization capabilities.
> My SCM, database, and clustering skills leave a lot to be desired,
> mainly because I haven't had any real use for them in my job. Also,
> I'm entirely useless at design, unless you like plain, unformatted
> text, and stick figures. Anything HTML is liable to be compliant,
> just ugly and/or boring.
>
> I don't have any specific goals in mind for getting into
> Infrastructure; as I said, I'd be happy to help out with anything that
> could use some extra hands.
>
> I think that pretty well covers things. Geez, I should have just
> updated my resume; it might have been easier, if a little more
> glossed-over.
> Have a nice day.
Jima who? :) Make sure you can come to the meetings in #fedora-meeting
(http://fedoraproject.org/wiki/Infrastructure/Meetings) Also take a
look at https://hosted.fedoraproject.org/projects/fedora-infrastructure/
and see if there's anything in particular you're interested in. If not
we can always use scripting help with our current scripts and future stuff.
-Mike
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
2011/11/21 Phil Meyer <pmeyer(a)themeyerfarm.com>
> On 11/20/2011 05:21 PM, Francesco Frassinelli wrote:
> > Hi all,
> > I need to boot a livecd on some hard disk less clients. I tried to use
> > livecd-iso-to-pxe, but in my case it unacceptable to load the whole
> > iso into initrd (the iso is not small).
> > I made a custom livecd adding dracut-network package, I mounted
> > squashfs/root image, exported with nfs, and I've tried to boot the
> > clients with root=nfs:192.168.1.50:/home/frafra/root/ selinux=0, but
> > Fedora gives me many errors because it can't write on it.
> > I found this old thread
> > http://comments.gmane.org/gmane.linux.redhat.fedora.livecd/4261 but it
> > doesn't work for me.
> > Is there a way to get a livecd behaviour with this nfs directory? Or
> > can I combine the isolinux.cfg livecd options with
> > root=nfs:192.168.1.50:/home/frafra/ (where it could found the iso or
> > the mounted iso)?
> > I'm using dnsmasq with its internal tftp server, which gives vmlinuz0
> > and initrd0.img (copied from livecd), pxelinux.0 and a configuration
> > file with the above root=nfs:[...] selinux=0 options.
>
> The real issue is not the size of the iso, but using tftp protocol to
> load it.
>
> TFTP needs to ack each segment before the next is sent, thus severely
> throttling throughput.
>
> On a 100BT interface, tfpt maxes out at about 2MB/sec.
> On a 1000BT interface, tftp maxes out at about 15MB/sec
>
>
> I would propose using a different method for identifying the initrd to
> dracut during the PXE boot process.
>
> Current:
> KERNEL /images/centos_server_kvm/vmlinuz0
> APPEND rootflags=loop initrd=/images/centos_server_kvm/initrd0.img
> root=live:/centos_server_kvm.iso rootfstype=auto ro liveimg quiet rhgb
> rd.luks=0 rd.md=0 rd.dm=0
>
> Proposed:
> KERNEL /images/centos_server_kvm/vmlinuz0
> APPEND rootflags=loop
> initrd=http://mymirror.mycompany.com/images/centos_server_kvm/initrd0.imgro…
> rootfstype=auto ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
>
> That would literally shave minutes off of boot times by increasing
> throughput of the large image by a factor of 10 or more.
>
> This is somewhat of a paradox issue, because many of the network and
> protocol drivers are within the initrd images. Surely there must be a
> way ...
>
I agree with you but keep in mind that loading initrd is a slow process
because it could be big, and it could be big if you load into it the whole
iso. As Alan said before, you could transfer the iso into ram using http(s)
or ftp, so initrd loading is a minor issue.
In my opinion is that if you have a big iso and many clients, it has no
sense to load the whole image, so I would like to adopt a solution where
everything could be fetched only when you need it.
I thought about a possible workaround for this issue: does exist a way to
use a nfsroot as liveimage?
Livecd process mounts iso rootsfs and then writes on ram, so, it could be
easy to get this behaviour with an another root filesystem, right?
Francesco Frassinelli
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
