Networked Services

Jason Perrin
This presentation is at https://ocf.io/decal/slides/7
Sign in at https://ocf.io/decal/signin
Q&A: https://slido.com #OCF
What’s special about networked services?
● A lot!
● Without being connected to the network, who could ever access a computer?
○ Have to physically come to one location each time
● More security concerns
○ Can be publically accessible, so anyone could potentially exploit it
● Have to manage connected clients
○ Make sure enough clients can connect, but not get overloaded
○ Config tuning
● IPv4 vs IPv6
Sockets
● Wasn’t covered in networking, but sockets
are used heavily in unix
○ Most of the time you use them and don’t even
notice!
● Designed to provide a familiar and
common interface with the network
○ Resembles the same interface used for
reading/writing files
● Types of sockets
○ IPv4/IPv6 (typical internet communication)
○ UNIX socket (local communication)
○ Bunch of others that you’ll probably never use
(man 2 socket)
The socket connection process
● Listening program (service) creates a
socket and listens for incoming
connections
○ If you want it publically available, need to
use a port number
● Bunch of common functions given in
C for doing this
● Covered in both 168 (project 1) and
162 (hw 2) if you want more
information
How do you know what networked services are running?
● sudo netstat -l will show all active
ports/sockets, but you probably don’t care
about a bunch of internal unix sockets
● I usually use sudo netstat -plunt
because I remember it, but if you leave off
the n then it will show names
corresponding to ports, which can be nice.
p is nice, because it shows the programs
corresponding to each port!
(This is running on an IRC server, and as you can
see, there are a lot of services running with
network connectivity)
Popular networked service examples
A (relatively) small list of examples
● I’ll go over each of these briefly, there are many more, but these are just some
the OCF uses or that I have commonly seen:
○ LDAP
○ NFS
○ DNS
○ SSH
○ Kerberos
○ NTP
○ Web servers
○ Mail servers
○ Databases
○ Load balancers
● The list goes on and on and on...
LDAP: Lightweight Directory Access Protocol
● A relatively simple directory service that stores
data about users
○ For instance, this is my ldap entry at the OCF ->
● Often used for authentication when supporting
Windows, since it has quite widespread support
● Organized hierarchically, as shown in the “dn”
attribute (EDU, then Berkeley, then OCF, etc.)
● Needs to be accessible over the network for
computers to authenticate with LDAP
○ Would be wasteful for them to all have a server of their
own, and then those would need to synchronize
somehow!
NFS: Network File System
● A networked service to share files
between multiple servers
● This makes it easier, for instance, to
edit files on one server, and have
them run on another server
○ We do this for OCF web hosting
● Also nice for sharing files between
multiple hosts!
● Can have more storage on a host than
otherwise would be possible, because
it’s actually located somewhere else
(networks are cool)
DNS: Domain Name System
● Mentioned already in the networking
lecture if you want more details
● Essentially maps from something like
“ocf.berkeley.edu” (a domain name)
-> 169.229.226.23 (an IP)
○ Or to 2607:f140:8801::1:23 if you like IPv6
● Nice for humans to use, since we are
bad at remembering numbers and
very good at remembering fun names
SSH: Secure Shell
● What you have all been using to access
your VMs! (openssh)
● This is a service just as much as any
other, it’s just particularly important to
keep running because connecting and
fixing stuff is much harder if it breaks.
● Actually can be used as a tunnel to
encrypt other kinds of traffic, so for
instance can browse the web by
tunneling it over SSH
Kerberos
● A (quite complicated) network
authentication protocol based on tickets
○ Allows a user to authenticate once, obtain a ticket,
and not have to authenticate again until the ticket
expires (who wants to type their password
hundreds of times?)
● Often used with Windows, it’s been the
default since Windows 2000, but is quite
useful on Unix too, especially if you have to
support mixed Windows + Unix clients!
● Sidenote: This is what the OCF uses so that when you
log in, you can SSH to ssh.ocf.berkeley.edu without
entering your password again
NTP
● Wouldn’t typically think that a
system’s clock could be a problem
● One of the oldest protocols still in
current use (in use since before 1985)
● Some protocols need the clock to be
quite accurate (SSL certs, Kerberos,
etc.)
Web Servers
● NGINX (pronounced engine-x)
○ Designed for concurrency, newer and
generally faster than Apache, often used a
proxy in front of other services
● Apache
○ Slower than nginx, but more established
and generally has more features and
modules available
● Plenty more (lighttpd, cherokee, etc.), (if you look up Apache, you’ll find lots of
but NGINX and Apache are the main these feathers from various years)
two you will encounter over and over
Mail Servers
● I’m not as familiar with these
personally, but there’s a lot of choices
out there.
● Take your mail and deliver it
somewhere else (can also store it on
the machine they are running on so
you can view it there)
● Postfix and Dovecot are both popular
examples
Databases
● Databases can be accessible from the
network too!
○ PostgreSQL and MySQL/MariaDB are the
most common, and for both if you want
other users to be able to access the
database, you’d want to make it available
over the network
Load balancers
● The key here is that handling requests for a
service all in one place doesn’t scale since
you can have millions of clients at a time
● HAProxy
○ Common open-source load balancer
○ Accepts connections, and then sends them on to
somewhere else to be answered (typically
forwards on to another server)
● NGINX is actually starting to do this too,
along with being a web and proxy server
Lab 7!
● As you work through all of this stuff, keep in mind your VMs have a firewall, so
only certain traffic is let through:
○ All SSH traffic should be fine (that’s how you are able to connect)
○ DNS traffic is let through too for this lab (port 53).
○ NFS traffic should be let through too to allow you to connect to the staff VM and read/write files.
● Let me know if you have questions (post on Slido, on Piazza, or ask in person)