From: ibuprofin@painkiller.example.tld.invalid
On Tue, 29 Jan 2013, in the Usenet newsgroup alt.os.linux.mandriva, in article
, Adam wrote:
>Moe Trin wrote:
>Medical, probably a respiratory infection. Definitely sick with
>something, also get out of breath easily. Just started on
>antibiotics.
Had you gotten a flu shot, or is that disallowed? I usually get one
as soon as they become available. Apparently not all bothered, and a
lot of people are reporting flu-like symptoms. The vaccine is rather
hard to find now but the local health authorities are claiming it's
still worth getting if you hadn't (and can _find_ it).
>> DHCP is the more common setup because it usually works and requires
>> little to no thinking on the part of the person setting up the
>> computer. The technical burden is transferred to the person who has
>> to set up the DHCP server
>When I first got DSL I used DHCP to get everything up ASAP, but IIRC
>somebody somewhere suggested using static addressing so I switched.
With a single computer, it's often a toss-up. You rarely will try to
connect to "that" IP, so it's more or less irrelevant what it is.
When you have more than one computer, or as in your case you've got a
networked printer, it becomes more desirable to use static addressing.
Microsoft gets around the problem by ignoring security and using
NetBIOS names - same rough concept as MulticastDNS (Avahi).
>>>> I'd suggest setting the router to hand out a "fixed" wireless
>>>> address based on the hardware address associated with helot's
>>>> wireless interface
>I don't see any way for my router to do that. The router just hands
>out an unused address within the range I've specified for DHCP,
>currently 192.168.1.55 through 192.168.1.62.
I don't know your router, but there should be a way to do so as this
is an option specified by the RFC2131 ("Dynamic Host Configuration
Protocol") standard. Not even a vendor extension (RFC2132).
>Would enabling MAC authentication on the router help?
I don't believe so, but that could be a terminology issue. I'm used
to hearing the term used with wireless links as an easily spoof-able
password token.
>> let's start by talking about the routing problem [...]
>> Now let's get complicated and have BOTH interfaces up, and some
>> systems reachable on the Ethernet, some only on wireless.
>I'm doing that already, stolid using its eth0 and eris using its
>wlan0, and it all works. I thought that was because the systems
>didn't communicate with each other directly, but only through the
>router.
Minor confusion - if everyone can talk, the router is doing secret
things (bridging, or acting as a network switch). A clue would be to
note what MAC addresses are associated with the IPs in the output of
the 'arp -a' command. If stolid sees the address of eris associated
with the MAC address of the router, that's bridging, while if stolid
sees the MAC address of eris's wlan0 interface, that's switching. If
everyone can talk, you're down to the DHCP configuration issue.
>Both systems can also use the network printer, although I don't know
>what will happen if both try to use it at the same time.
First job in gets printed, followed by the second, etc. Nothing
unusual. The printer is printing jobs, not individual pages.
>Is that what I'm already doing? Even if I don't quite understand that
>explanation yet? :-)
You don't have to understand - the router does ;-)
[nmap and netstat]
>>> [stolid] is its own DNS server, but shouldn't be acting as one for
>>> anything else.
>> Do you mean it's set to serve for your LAN?
>I think it /is/ set, although I don't think I want it to be.
Terminology - what I meant is that stolid is an authoritative server
for 192.168.1.x (there are suitable config files in /var/named/), and
a client can use the DNS to resolve your local systems. Because you
have all hosts in all /etc/hosts files, this isn't needed. Now as for
which interface it's listening to:
>tcp 0 0 stolid.aplomb.invali:domain *:* LISTEN 3512/named
>tcp 0 0 localhost.localdomai:domain *:* LISTEN 3512/named
>udp 0 0 stolid.aplomb.in:domain *:* 3512/named
>udp 0 0 localhost.locald:domain *:* 3512/named
That says it's listening on both the loopback (localhost.localdomai)
and the network (stolid.aplomb.in) which is the default mode. You can
restrict this two ways - a "listen-on" option in /etc/named.conf:
(" listen-on { 127.0.0.1}; ") or a firewall rule.
>I want all the other systems to have connectivity even if stolid isn't
>available.
/etc/resolv.conf - have it point to the name servers you want to use.
>> Betraying my lack of knowledge of your LAN
>Do I really have such an unusual or nonstandard configuration?
No - it's just that there is more than one way to do it, and I don't
know which one you've chosen.
>> I thought you had everyone using the router as the DNS, and it was
>> set up as a forwarder (asking the Verizon servers to resolve names
>> it didn't know about).
>"stolid" (the only one completely configured IMO) is its own DNS.
OK - the "common" way is that all hosts run DHCP, and get their IP
address from the DHCP server (on the router). This means a /etc/hosts
file won't be up to date as it's not monitoring what addresses the
server is handing out. The usual solution is to let the DHCP server
update the local name server (dynamic DNS), and this server is located
in the router. One of the DHCP options is to specify an IP address of
a name server the clients should use, and the DHCP client on each host
sticks that data into /etc/resolv.conf for you. That server is
"authoritative" for the LAN, and either forwards all other requests to
an outside name server, or recursively resolves those requests on it's
own.
For those using static addresses, the /etc/hosts solution answers the
local addressing, and /etc/resolv.conf is configured to point to some
name server[s]. (You may have to beat the snot out of some "Let me do
this for you" helper tool to make it leave that file alone, but that's
another war.) The name servers could be a local one (such as the one
on the router, or a local host running a forwarder or recursive name
server), or some name server "out there" (ISP, or a public server).
>> I recall you had it set to forward to an open-DNS server such as
>> ultradns.net or opendns.com - or google, or...
>The other systems are currently set to forward to the Verizon DNSs
>just to get them up ASAP, though I intend to change those to some
>open-DNS
Terminology again - "forward" is something a name server does. You
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
