Re: yum error creating exported file system for diskless client
by Fred Brier
I went through the files in the yum.repos.d directory including fedora.repo, fedora-updates.rep and fedora-updates-testing.repo, and swapped out the baseurl lines with macro variables with an absolute repo's URL, ie:
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
baseurl=http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/releases/13/E...
That worked. I was able to install base OS and follow all the other steps. I am now having a different issue with the tftp timing out on the diskless workstation, but that may be related to the motherboard's built-in Ethernet port or a conflict with dnsmasq and tftpd. Still working on that, but if taking the macro variables out of the baseurl gives anyone a hint as to what this problem was, please let me know. I was not having any problems with normal yum updates, just installing the OS into a different directory, so I will probably switch the baseurl back. Thank you for any help.
On 02/06/2011 04:22 AM, Frederick N. Brier wrote:
> I was following the directions in Chapter 18. Setting Up A Remote Diskless System <https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administratio...> and got to 18.3 <https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administratio...> where it said Fedora could be installed to a directory that would be exported. I had previously created a 2GB ext4 LVM volume and mounted it at /diskless/myhostname and then attempted to execute the yum command:
>
> [root@myserver yum.repos.d]# yum groupinstall Base --installroot=/diskless/myhostname
> Loaded plugins: refresh-packagekit
> fedora/metalink | 18 kB 00:00
> Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x... error was
> No repomd file
> Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
> [root@myserver yum.repos.d]#
>
> yum update works fine. I tried doing a "yum clean all". Did not fix it. What step am I missing? Thank you.
13 years, 4 months
Shared to other computers
by Jack Howarth
Has anyone managed to get the "Shared to other computers" option described in...
http://www.techerator.com/2010/01/how-to-setup-internet-connection-sharin...
to work under Fedora 14 or 15 when both network interfaces are ethernet devices?
I have an Asus A8N-SLI Premium motherboard with eth1 attached to the external ethernet
and eth0 configured in the Network Connections dialog to use the "Shared to other
computers" method. When I attach a Fedora 15 i386 laptop to eth0 via an ethernet patch cable,
under Fedora 14 the connection was eventually made but the dns didn't work. Under
Fedora 15, the laptop shows a red X for the network connection. The documentation on
this method of internet sharing with two ethernet cards is very sparse and very
unclear on whether additional dnsmasq or dhcp support is required to be configured.
Jack
13 years
Re: Static ethernet connection
by Geoffrey Leach
On 01/02/2012 05:25:25 PM, Reindl Harald wrote:
>
>
> Am 03.01.2012 02:22, schrieb Geoffrey Leach:
> > I need to set up an ethernet connection to a device that needs a
> static
> > IP address. Can anyone point me to doc on how to do this?
>
> * disable networkmanager
> * write a network-script as all the years before
>
> cat /etc/sysconfig/network-scripts/ifcfg-eth0
> DEVICE=eth0
> IPADDR=192.168.1.2
> NETWORK=192.168.1.0
> BROADCAST=192.168.1.255
> NETMASK=255.255.255.0
> TYPE=Ethernet
> BOOTPROTO=static
> ONBOOT=yes
> NM_CONTROLLED=no
> USERCTL=no
> IPV6INIT=no
>
> * chkconfig network on
> * service network start
Reindl, thanks.
I'm not sure that the network service is available on Fedora 16, which
is OK, because this works fine as is, along with "ifup eth0".
ONBOOT=yes does not work in my context. BTW, what is BOOTPROTO=static?
As it happens, my problem turned out to be that dnsmasq was not
running. It used to be, as you know, that there was a nice service
configuration tool that would prompt you as to what you might need. No
longer (sigh).
Thanks again.
12 years, 5 months
Re: Static ethernet connection
by T.C. Hollingsworth
On Mon, Jan 2, 2012 at 9:56 PM, Geoffrey Leach <geoff(a)hughes.net> wrote:
> I'm not sure that the network service is available on Fedora 16, which
> is OK, because this works fine as is, along with "ifup eth0".
> ONBOOT=yes does not work in my context. BTW, what is BOOTPROTO=static?
The network service is still available on F16, though it uses
systemd's SysV comptaibility mode. Either "systemctl enable
network.service" or "chkconfig network on" will enable it.
"BOOTPROTO=dhcp" configures your connection to obtain an IP address
from a DHCP server, while "BOOTPROTO=static" allows you to assign a
static IP address. The reason it's called "BOOTPROTO" is historical:
http://en.wikipedia.org/wiki/Bootp
> As it happens, my problem turned out to be that dnsmasq was not
> running. It used to be, as you know, that there was a nice service
> configuration tool that would prompt you as to what you might need. No
> longer (sigh).
Actually, system-config-services got ported to systemd, and works
rather nicely with it.
-T.C.
12 years, 5 months
Re: nscd and DNS cache
by Ed Greshko
On 05/16/2012 02:54 PM, JD wrote:
> I understand the libs are what make calls to the resolver. But even
> the resolver must look
> at /etc/resolv.conf.
Well, you did say: "Am I to believe that the browser is NOT using /etc/resolv.conf"
which to me reads that you were thinking that somehow the browser itself should be
using resolv.conf. I'm sorry if I misread what you wrote.
> If it is empty, NOTHING gets resolved.
Not "entirely" true.
With named not running.....
[egreshko@f16-1 ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
#search greshko.com
#nameserver 192.168.0.55
[egreshko@f16-1 ~]$ ping misty
PING misty (192.168.0.55) 56(84) bytes of data.
64 bytes from misty (192.168.0.55): icmp_req=1 ttl=64 time=1.99 ms
since /etc/nsswitch.conf contains
hosts: files dns
and /etc/hosts contains
192.168.0.55 misty
if you take the "files" out of the hosts line....then NOTHING gets resolved.
> I was using nscd thinking it is a lightweight caching resolver. But as
> it turns out it is useless.
> Time for fedora to bury it :)
> Re: My router: it does very little if any caching - and has no
> configuration for it at all.
>
> I will try bind.
I've not used it....but have heard good things about dnsmasq which, according to yum
info, is A lightweight DHCP/caching DNS server.
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
12 years, 1 month
Re: nscd and DNS cache
by Ed Greshko
On 05/17/2012 03:52 AM, JD wrote:
> Well, after running dnsmasq with the configuration I just emailed,
> I see the following behavior of firefox vs. running nslookup on command line.
>
> FF, even after resolving google.com only a minute ago, is still spinning saying:
> lookup up www.google.com
> whereas , on the command line, I run nslookup www.google.com
> and almost instantly, I get
> Server: 127.0.0.1
> Address: 127.0.0.1#53
>
> Non-authoritative answer:
> Name: google.com
> Address: 74.125.239.1
> Name: google.com
> Address: 74.125.239.2
> Name: google.com
> Address: 74.125.239.3
> Name: google.com
> Address: 74.125.239.4
> Name: google.com
> Address: 74.125.239.5
> Name: google.com
> Address: 74.125.239.6
> Name: google.com
> Address: 74.125.239.7
> Name: google.com
> Address: 74.125.239.8
> Name: google.com
> Address: 74.125.239.9
> Name: google.com
> Address: 74.125.239.14
> Name: google.com
> Address: 74.125.239.0
>
> and FF is still spinning waiting for the resolution.
>
> Does anyone see this discrepancy?
No....
Have you tried a different browser? Chrome, or konqueror for example?
One SWAG would be to set network.dns.disableIPv6 to true in about:config.
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
12 years, 1 month
Re: nscd and DNS cache
by JD
On 05/16/2012 06:21 PM, Ed Greshko wrote:
> On 05/17/2012 03:52 AM, JD wrote:
>> Well, after running dnsmasq with the configuration I just emailed,
>> I see the following behavior of firefox vs. running nslookup on command line.
>>
>> FF, even after resolving google.com only a minute ago, is still spinning saying:
>> lookup up www.google.com
>> whereas , on the command line, I run nslookup www.google.com
>> and almost instantly, I get
>> Server: 127.0.0.1
>> Address: 127.0.0.1#53
>>
>> Non-authoritative answer:
>> Name: google.com
>> Address: 74.125.239.1
>> Name: google.com
>> Address: 74.125.239.2
>> Name: google.com
>> Address: 74.125.239.3
>> Name: google.com
>> Address: 74.125.239.4
>> Name: google.com
>> Address: 74.125.239.5
>> Name: google.com
>> Address: 74.125.239.6
>> Name: google.com
>> Address: 74.125.239.7
>> Name: google.com
>> Address: 74.125.239.8
>> Name: google.com
>> Address: 74.125.239.9
>> Name: google.com
>> Address: 74.125.239.14
>> Name: google.com
>> Address: 74.125.239.0
>>
>> and FF is still spinning waiting for the resolution.
>>
>> Does anyone see this discrepancy?
> No....
>
> Have you tried a different browser? Chrome, or konqueror for example?
>
> One SWAG would be to set network.dns.disableIPv6 to true in about:config.
>
That value is already set to false.
Yes I did try Chrome.
Chrome resolves domain names as fast as nslookup .
After I browsed to a domain using Chrome, and it almost immediately
resolved and it brought in the page,
I quickly clicked on the FF workspace and browsed to same domain.
FF went into the looking up ...... spin dance.
Could it be that FF is not using same library as nslookup and Chrome?
12 years, 1 month
Re: nscd and DNS cache
by Gordon Messmer
On 05/15/2012 07:11 PM, JD wrote:
> I have nscd running.
> /etc/resolv.conf starts out with
> nameserver 127.0.0.1
If you're actually running a local caching name server (bind or
dnsmasq), you don't need nscd. Running both is overkill. You're going
to waste memory by having everything cached in two different places.
You can't test nscd with nslookup, dig, or host. All of those are DNS
tools. They'll use the contents of resolv.conf, but they do not use the
libc host lookup functions, and therefore they will not use nscd. If
you want to test nscd, you should use "getent host".
12 years
Re: nscd and DNS cache
by JD
On Thu, May 17, 2012 at 8:59 PM, Gordon Messmer <yinyang(a)eburg.com> wrote:
> On 05/15/2012 07:11 PM, JD wrote:
>>
>> I have nscd running.
>> /etc/resolv.conf starts out with
>> nameserver 127.0.0.1
>
>
> If you're actually running a local caching name server (bind or dnsmasq),
> you don't need nscd. Running both is overkill. You're going to waste
> memory by having everything cached in two different places.
>
> You can't test nscd with nslookup, dig, or host. All of those are DNS
> tools. They'll use the contents of resolv.conf, but they do not use the
> libc host lookup functions, and therefore they will not use nscd. If you
> want to test nscd, you should use "getent host".
>
That's excellent info. contradicts what other people have replied.
12 years
Re: nscd and DNS cache
by Ed Greshko
On 05/18/2012 03:22 PM, JD wrote:
> So, what's to prevent someone from simply modifying dnsmasq
> (or any other open source caching name resolver) to change
> the expiration time to a value greater than what the owner
> of the domain wants? Sure it may result in using stale
> ip addresses once in a while. I think that's more tolerable than
> having to wait anywhere from 10 to 30 seconds to resolve every
> new name browsed to; (new relative to contents of the cache).
Nothing "stops" anyone from doing that....except they'd be mucking with the DNS
system in ways unintended/unexpected. I personally wouldn't use that software.
If you need to wait that long for address resolution then you've either got a *very*
slow network, your link is saturated, or the DNS server you're contacting is a poor
performer.
I had an ISP here in Taiwan that required you to use their DNS servers. They blocked
port 53 outbound from their network. Their DNS servers would get overloaded from
time to time...but even then I rarely waited for more than a second or two.
Some people prefer to set their resolv.conf to point to 8.8.8.8 and 8.8.4.4 which are
2 of google's public nameservers that are very fast.
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
12 years
