[sf-lug] ubuntu 16.04
jim
jim at well.com
Fri Aug 5 09:42:49 PDT 2016
Thanks greatly, Asheesh. (BTW I mis-wrote the
problem--inbound worked fine, outbound was the
problem: we got email coming in but could not
send or even reply successfully.
"ufw" you say? Good to know, and thanks for
the links.
best,
jim
PS: we got some advice from experts who told us to
"divide by two", which is a standard problem solving
technique that requires that one understands the
problem domain well enough to know at least
approximately the beginning and the end and enough
of the in-between to find some "place" in the middle
to start testing: "is it broke here? then test a
point between the beginning and "here"; if not, then
test a point between "here" and the end.
clearly I did not understand the network side of
things sufficiently to do so: the experts then told
us to try using the lo socket.
I understand that lo means local and/or loopback;
it's IP address is 127.0.0.1 and is defined as the
local/loopback socket for each machine that supports
IP. (I'm using the term "socket) loosely, assuming
some port is also used with the IP address.) It is
like any ethernet socket but it does not connect to
an external host; sending packets to lo sends packets
to the same machine, thus one can test to see if the
problem is on the local machine or not--if not, then
the problem may be in the LAN or the gateway to the
internet or some managed feature "out there" in the
ISP's infrastructure....
I'm still wondering how lo is in the middle. Is
there some helpful a(i.e. simple) diagram or doc that
describes the beginning to end of the network system?
For example, I, the poor user, click the mouse to
initiate some network activity. My click triggers some
program in user space to create some data and bind
that data with a socket, which is an IP address and a
port:
Specifically, I use a web browser to return the
sf-lug top-level web page. The web browser has claimed
a port on the local machine and sends an HTTP request
to sf-lug.org:80 (which these days is 198.144.194.238:80).
My browser sends this request to the "top" of the
outbound TCP stack on my computer, which triggers the
creation of a network packet, which is built by adding
little bits of data as the packet goes "down" the stack
to the ethernet interface device.
The ethernet interface on my machine sends the
fully-built packet onto the ethernet cable as a burst of
"bits", which are electrons. The cable connects to a
network switch device in my room, which is connected to
some kind of router in my room, which is connected to
some kind of modem device in my room that converts the
bits on my ethernet cables to waves of some kind that it
sends on a cable from my room to some place not in my
house where my ISP has its infrastructure.
The ISP system gets the packet and inspects its outer
layer data and adds a bit of data to identify its system
and forwards the packet to some other "node" (place where
there are some internet machines), which either is the
target (sf-lug.org host machine) or adds a little more
data to identify itself and then forwards the packet to
yet another node. So there is a chain of hosts (nodes)
between my computer and the sf-lug.org host machine.
At some point, the packet gets to the host machine
that supports the sf-lug.org web site, which brings the
packet "up" its TCP stack, unwrapping data layers as the
packet goes up so that the software that is using port 80
on that host (the web server) gets the data that my web
browser created, an HTTP request that the sf-lug.org system
return the top-level web page.
The sf-lug.org web server binds the data of the web
page with a little data for the top level of the TCP stack,
which triggers the stack to send the packet down through
its layers, adding a little bit of data for each layer. The
complete packet goes to the ethernet interface device on
the sf-lug.org host machine; the packet includes information
identifying the hosts that are in the chain between the
sf-lug.org host and my computer.
The packet gets through my ISP infrastructure, to the
modem in my room to the router in my room to the switch in
my room to the ethernet interface device on my computer
and "up the TCP stack" of my computer to the application
that claims the socket that originated the request (my web
browser).
So where in that flow is a firewall on my machine? A part
of the TCP stack? There's a feature called IP tables that one
can configure to manage how one's machine accepts or rejects
or drops or forwards packets. I tried to learn about this
and was frustrated by the seeming indistinct terms (mainly
not rigorously defined, for example, what exactly is a
"target"?). Just how exactly does the IP tables software work
with the TCP and/or UDP and/or any other network stacks?
The /etc/ directory lists a number of configuration files
that have to do with networking. My computer system software
does its thing by running programs, which make calls to
libraries (which are stored as files that have lots of
different software routines in them). There are gobs of
libraries for lots of different purposes. One set of
libraries has to do with networking. It would be nice for
me to learn where there is a simple diagram or doc that
describes the software involved in networking and shows the
relationships between the various software elements.
Oh yeah: which device drivers (modules) are involved
and how do they fit in the scheme of things?
Well, I got that off of my chest.
On 08/05/2016 01:12 PM, Asheesh Laroia wrote:
> Hi Jim!
>
> Did you check if the Ubuntu installs have "ufw" ("Uncomplicated
> Firewall") installed? If not, then that might be good to check. Here's
> some more info:
>
> - https://help.ubuntu.com/12.04/serverguide/firewall.html
> <https://help.ubuntu.com/12.04/serverguide/firewall.html>
>
> -
> https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-14-04
> <https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-14-04>
>
> I can't quite tell from the 'net if this is enabled by default, or
> merely available by default, but if it's enabled by default, that
> would (I believe) explain the behavior you're seeing.
>
> Cheers,
>
> Asheesh.
>
> On Fri, Aug 5, 2016 at 1:48 AM, jim <jim at well.com
> <mailto:jim at well.com>> wrote:
>
>
> Ron and I have been trying to get servers
> working on old Dell boxes running Ubuntu 12.04.x.
> We could not get any of the hosts to support
> inbound network sessions (such as sshd and
> apache2 and exim4). My latest suspicion (on
> the order of superstition) is that the people
> who configured the old Dells did something to
> the BIOS that restricted use to the enterprise'
> purpose.
> Ron and I took a long break.
> I bought a new computer from Zareason and
> asked them to install sshd and apache2 and
> exim4 on it. I'm now logged in and looking at
> various features. It's really different from
> AT&T Sys V rev iii and also fairly different
> from Ubuntu 12.04.x too. And that's depressing.
> I'd be interested in a KISS Linux distro.
>
> It looks, at first blush, like Zareason
> techs did a good job: sshe and apache2 both
> work fine. I'm delaying facing exim4 for now.
> My new host does not have a GUI, just the
> command line, which mainly works for me,
> excepting some GUI features for which I've
> not got GUI experience (wifi for example).
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com <mailto:sf-lug at linuxmafia.com>
> http://linuxmafia.com/mailman/listinfo/sf-lug
> <http://linuxmafia.com/mailman/listinfo/sf-lug>
> Information about SF-LUG is at http://www.sf-lug.org/
>
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20160805/692ec826/attachment.html>
More information about the sf-lug
mailing list