From: ibuprofin@painkiller.example.tld.invalid
On Sun, 13 Jan 2013, in the Usenet newsgroup alt.os.linux.mandriva, in article
, Adam wrote:
>Moe Trin wrote:
[Thinkpad T60]
>I've decided to take a few days off from configuring the laptop until
>my frustration at it goes away. :-) After all, I don't /need/ to use
>the laptop, and it's supposed to be a "fun" hobby project. I've
>already checked that there's no need for an RMA.
That's fine - there is no need for hurry. You don't need it in class
yet, right? ;-)
>One thing I never considered was manual configuration vs. DHCP for it.
I've always used a manual configuration for IPv4 on Ethernet because
none of the systems go walkies. Second, because I'm using RFC1918
address space at home, I have enough IP addresses available for the
resident (and even visiting) hardware. Third, I can figure out how to
kick the boot scripts in the right place so that I can have static
addresses. Those three facts eliminated the reasons for using dynamic
addressing, and allow me to put relatively simple firewall rules in
place on the systems. With a laptop, it's not very common to get an
Ethernet connection "out there", so the fixed address is suitable. On
the other hand, the wireless link on a laptop may visit any number of
different places with different IP ranges, etc., so DHCP is more
suitable/desirable for that interface.
>Everything else on my home LAN has a fixed address.
I _thought_ they were getting IPs from the router - and the _router_
was configured to hand out specific IPs to specific MACs. Yes, that
is static addressing, but it's still using DHCP.
>I gather that public hotspots use DHCP, but which should helot's
>wireless configuration use at home? Should I just have it use DHCP
>wherever it is (which would involve some router configuration)?
Yes, the public hot-spots are DHCP. Because the wireless side of helot
does indeed go out and about, I'd suggest setting it for DHCP. At home
if you're using the wireless, I'd suggest setting the router to hand
out a "fixed" wireless address based on the hardware address associated
with helot's wireless interface (what is shown by "/sbin/ifconfig
wlan0"). If you are also using it on Ethernet, either set that with a
static address, _OR_ set the router to give out a "fixed" address based
on the MAC address of the Ethernet interface (what is shown by
"/sbin/ifconfig eth0"). My understanding of your setup was you are
using one range on the Ethernet (ex: 192.168.1.0/28), and a separate
range (ex: 192.168.1.16/28) for the wireless. Note that if you _do_
run wireless AND Ethernet connections at the same time, only one of
those can be helot - maybe the other is 'chattel', peon', serf',
'thrall' 'vassel' or something.
>Right now its wired connection uses a fixed address.
Which is fine - you can use either, but if you try to use BOTH at the
SAME TIME, things can get mind-boggling.
>>> So far, "killall" gets rid of most of [unwanted services]
>> How many services/daemons was that?
>Not many, maybe 4.
OK - that should be fixable.
>> What you now should do is take the list of unwanted
>> services/daemons and determine how they are being started.
>Yep, but I think my first priority is to get a reliable wireless
>connection between the laptop and my own home LAN.
Your decision, but I'd suggest securing the system first. It shouldn't
be that difficult.
>It looks to me that ssh configuration is "one way", meaning I'll have
>to (for example) configure stolid ssh-ing in to eris (which requires
>setup on both systems), and then separately configure eris ssh-ing to
>stolid.
Well... you've got to have a client set up on the one you're coming
from, and a server set up on the one you're going to - so yes, that is
effectively one way servers on each independent of each other. But
how this is done comes back to the authentication scheme used.
Assuming a minimal setup, you could set up the server to accept a
password type of login, and once the systems learn about each other
(key fingerprints shared), then one basic configuration on each
system handles all (set up stolid, and you can then connect from eris
OR helot and so on). If you don't want to use a login password, you
have to carry an shared type of key that you generate using
'ssh-keygen' (then sticking the public and private keys in the
appropriate files on client and server). I'm using a much more
complicated scheme, because I may be connecting from anywhere, with
effectively "unknown" hardware. It's a password type of scheme,
except the password has one-time components. Can be fun, and I have
locked myself out more than once.
>BTW would it be possible for the laptop to ssh into stolid when I'm
>away from home? My WAN IP is usually 96.238.xxx.xxx (not static) and
>stolid is in 192.168.1.0/26 under that.
Yes, but things can be a bit complicated. BRIEFLY, you have to set up
the router to forward incoming connections to port 22 on the WAN-IP
to port 22 on stolid. That shouldn't be that hard (but I don't know
your router, so I don't know the specific steps). From outside, you
would then "ssh 96.238.123.456" (yes, I know), and the router then
forwards the packets both ways. A MAJOR PROBLEM is that every 'bot
in the world is going to be stroking that address trying to log in
(using username of root and many others, and a bunch of passwords that
the skript-kiddie found under a rock on the "skript-kiddies-r-us"
web server. You can get around that problem by using certificates
(which essentially means your hardware outside), or by severely
limiting the addresses you allow to connect. (I'm using that trick
to reduce the noise - you can only connect to my home server from just
three external IP ranges - a /22 and two /24s). It get's even more fun
if you're traveling and want to connect with someone else's hardware.
Definitely not something simple.
I think we discussed this some time ago. Your router is _probably_
dropping all "new" connections inbound. Were you to nmap it from an
outside IP (don't - it may make people unhappy if you try), you'd
likely see it report all "closed" or "filtered". I think you actually
did scan it once and found that, or only a couple of ports, and none
were "open". To change this, you've got to tell the router to forward
this or that port to this or that IP. Forwarding isn't enabled by
default, because the router has no easy way to read your mind and
figure out which of the possible LAN systems you want which traffic to
be forwarded to.
>I ran numerous nmap and netstat commands, and as the results came to
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
