78
Spring 2004 CMPE 151: Network Administration Lecture 5

Network Administration

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Network Administration

Spring 2004

CMPE 151: Network Administration

Lecture 5

Page 2: Network Administration

Spring 2004

Project Proposals Due by 05.13. Samples will be posted on the Web

page by later today.

Page 3: Network Administration

Spring 2004

More services… NFS and Samba.

Page 4: Network Administration

Spring 2004

Network File System (NFS)

Page 5: Network Administration

Spring 2004

File Systems Provide set of primitives that

abstract users from details of storage access and management.

Page 6: Network Administration

Spring 2004

Distributed File Systems

Promote sharing across machine boundaries.

Transparent access to files. Make diskless machines viable. Increase disk space availability by

avoiding duplication. Balance load among multiple

servers.

Page 7: Network Administration

Spring 2004

Sun Network File System De facto standard:

Mid 80’s. Widely adopted in academia and industry.

Provides transparent access to remote files.

Uses Sun RPC and XDR. NFS protocol defined as set of procedures and

corresponding arguments. Synchronous RPC:

Client blocks until it gets results from server.

Page 8: Network Administration

Spring 2004

Stateless server Remote procedure calls are self-

contained. Servers don’t need to keep state about

previous requests. Flush all modified data to disk before

returning from RPC call. Robustness.

No state to recover. Clients retry.

Page 9: Network Administration

Spring 2004

Location Transparency Client’s file name space includes

remote files. Shared remote files are exported by

server. They need to be remote-mounted by

client.

Page 10: Network Administration

Spring 2004

File system hierarchyClient/root

vmunix usr

staffstudents

Server 1/root

export

users

joe bob

Server 2/root

nfs

users

ann eve

Page 11: Network Administration

Spring 2004

Achieving Transparency Mount service.

Mount remote file systems in the client’s local file name space.

Mount service process runs on each node to provide RPC interface for mounting and unmounting file systems at client.

Runs at system boot time or user login time.

Page 12: Network Administration

Spring 2004

Automounter Dynamically mounts file systems. Runs as user-level process on clients

(daemon). Resolves references to unmounted

pathnames by mounting them on demand.

Maintains a table of mount points and the corresponding server(s); sends probes to server(s).

Primitive form of replication.

Page 13: Network Administration

Spring 2004

Transparency?

Early binding. Mount system call attaches remote

file system to local mount point. Client deals with host name once. But, mount needs to happen before

remote files become accessible.

Page 14: Network Administration

Spring 2004

Other Functions NFS file and directory operations:

read, write, create, delete, getattr, etc.

Access control: File and directory access permissions.

Path name translation: Lookup for each path component. Caching.

Page 15: Network Administration

Spring 2004

Implementation

UnixFS

NFSclient

VFS

Client

Unix Kernel

NFSserver

UnixFS

VFS

Server

Unix Kernel

Clientprocess

RPC

Page 16: Network Administration

Spring 2004

Observations NFS didn’t change the file system

API. Users access remote files with the

same operations used for local ones. If access is to remote file, NFS client

makes a remote procedure call to NSF server where file resides.

Page 17: Network Administration

Spring 2004

Remote Procedure Call (RPC)

Builds on message passing. Main idea: extend traditional (local)

procedure call to perform transfer of control and data across network.

Easy to use: analogous to local calls. But, procedure is executed by a different

process, probably on a different machine.

Fits very well with client-server model.

Page 18: Network Administration

Spring 2004

RPC Mechanism

1. Invoke RPC.2. Calling process suspends.3. Parameters passed across network to

target machine.4. Procedure executed remotely.5. When done, results passed back to

caller.6. Caller resumes execution.Is this synchronous or asynchronous?

Page 19: Network Administration

Spring 2004

RPC Advantages Easy to use. Well-known mechanism. Abstract data type

Client-server model. Server as collection of exported

procedures on some shared resource. Example: file server.

Reliable.

Page 20: Network Administration

Spring 2004

RPC Semantics (1) Delivery guarantees. “Maybe call”:

Clients cannot tell for sure whether remote procedure was executed or not due to message loss, server crash, etc.

Usually not acceptable.

Page 21: Network Administration

Spring 2004

RPC Semantics (2) “At-least-once” call:

Remote procedure executed at least once, but maybe more than once.

Retransmissions but no duplicate filtering.

Idempotent operations OK; e.g., reading data that is read-only.

Page 22: Network Administration

Spring 2004

RPC Semantics (3) “At-most-once” call

Most appropriate for non-idempotent operations.

Remote procedure executed 0 or 1 time, ie, exactly once or not at all.

Use of retransmissions and duplicate filtering.

Example: Birrel et al. implementation. Use of probes to check if server crashed.

Page 23: Network Administration

Spring 2004

RPC Implementation (1)

work

Caller Callee

Callpacket

Result

UserUserstub

RPCruntime

RPCruntime

Serverstub Server

call pckargs

xmit rcv unpk call

returnpckresult

xmitrcvunpkresult

return

Page 24: Network Administration

Spring 2004

RPC Implementation (2) RPC runtime mechanism

responsible for retransmissions, acknowledgments.

Stubs responsible for data packaging and un-packaging; AKA marshalling and un-marshalling:

putting data in form suitable for transmission. Example: Sun’s XDR.

Page 25: Network Administration

Spring 2004

Binding How to determine where server is?

Which procedure to call? “Resource discovery” problem

Name service: advertises servers and services.

Example: Birrel et al. uses Grapevine. Early versus late binding.

Early: server address and procedure name hard-coded in client.

Late: go to name service.

Page 26: Network Administration

Spring 2004

Synchronous and Asynchronous RPC

SynchronousAsynchronousClient Server Client Server

Page 27: Network Administration

Spring 2004

RPC Performance Sources of overhead

data copying scheduling and context switch.

Light-Weight RPC Shows that most invocations took place on a

single machine. LW-RPC: improve RPC performance for local

case. Optimizes data copying and thread scheduling

for local case.

Page 28: Network Administration

Spring 2004

Transport protocol Originally used UDP.

Better performance in LANs. NFS and RPC do their own reliability

checks. Most current implementations use

TCP. WANs: congestion control.

TCP officially integrated in NFS v.3.

Page 29: Network Administration

Spring 2004

Virtual File System (1) VFS added to UNIX kernel.

Location-transparent file access. Distinguishes between local and remote access.

@ client: Processes file system system calls to determine

whether access is local (passes it to UNIX FS) or remote (passes it to NFS client).

@ server: NFS server receives request and passes it to

local FS through VFS.

Page 30: Network Administration

Spring 2004

VFS (2)

If local, translates file handle to internal file id’s (in UNIX i-nodes).

V-node: If file local, reference to file’s i-node. If file remote, reference to file handle.

File handle: uniquely distinguishes file.

File system id I-node # I-node generation #

Page 31: Network Administration

Spring 2004

NFS caching File contents and attributes. Client versus server caching.

Client Server

$ $

Page 32: Network Administration

Spring 2004

Server caching Read:

Same as UNIX FS. Caching of file pages and attributes. Cache replacement uses LRU.

Write: Write through (as opposed to delayed

writes of conventional UNIX FS). Why? [Delayed writes: modified pages

written to disk when buffer space needed, sync operation (every 30 sec), file close].

Page 33: Network Administration

Spring 2004

Client caching (1) Timestamp-based cache

invalidation. Read:

Cached entries have TS with last-modified time.

Blocks assumed to be valid for TTL. TTL specified at mount time. Typically 3 sec for files.

Page 34: Network Administration

Spring 2004

Client caching (2) Write:

Modified pages marked and flushed to server at file close or sync (every 30 sec).

Consistency? Not always guaranteed! E.g., client modifies file; delay for

modification to reach servers + 3-sec window for cache validation from clients sharing file.

Page 35: Network Administration

Spring 2004

Cache validation Validation check performed when:

First reference to file after TTL expires. File open or new block fetched from server.

Done for all files (even if not being shared).

Expensive! Potentially, every 3 sec get file attributes. If needed invalidate all blocks. Fetch fresh copy when file is next accessed.

Page 36: Network Administration

Spring 2004

Network Information Service (NIS)

Page 37: Network Administration

Spring 2004

NIS Originally called Sun Yellow Pages.

NIS commands still start with “yp”. Administrative database.

Spans server and its clients. Server keeps authoritative copies of

system files. Server propagates database over

network. Maps in /var/yp.

Page 38: Network Administration

Spring 2004

Data files and the NIS database Data files edited with text editor. Updated files are then converted

into database format (hashing) using e.g., ypmake.

Example data file: /etc/passwd, /etc/group

Page 39: Network Administration

Spring 2004

Replication Slave servers can replicate

network maps. When master copy is updated,

updated copy needs to be pushed out to slavs (yppush and ypxfr).

Page 40: Network Administration

Spring 2004

NIS Operation ypbind runs on every machine;

detects a NIS server and returns its id to client.

Server used for all remaining queries. ypserv runs on servers (master and

slaves) accepting and answering queries by looking up NIS maps.

Page 41: Network Administration

Spring 2004

Samba

Page 42: Network Administration

Spring 2004

What is Samba? Allows resource sharing between

Unix-based and MS Windows-based systems.

“Samba is a freely available SMB server for Unix… Samba runs on a great many Unix variants (Linux, Solaris, …, FreeBSD, …, etc.)…” [www.samba.org/cifs/docs/what-is-smb.html]

Page 43: Network Administration

Spring 2004

How does it work? Set of UNIX applications running the

Server Message Block (SMB) protocol. SMB is the protocol MS Windows use

for client-server interactions over a network.

By running SMB, Unix systems appear as another MS Windows system.

smbd daemon.

Page 44: Network Administration

Spring 2004

Samba Services File sharing. Printer sharing. Client authentication.

Page 45: Network Administration

Spring 2004

SMB Protocol Request/response. Runs atop TCP/IP. E.g., file and print operations.

Open close, read, write, delete, etc. Queuing/dequeing files in printer

spool.

Page 46: Network Administration

Spring 2004

SMB Message Header + command/response. Header: protocol id, command

code, etc. Command: command parameters.

Page 47: Network Administration

Spring 2004

Establishing a SMB Connection Establish TCP connection. Negotiate protocol variant.

Client sends SMBnegprot. Client sends lists of variants it can speak. Server responds with index into client’s

list. Set session and login parameters.

Account name, passwd, workgroup name, etc.

Page 48: Network Administration

Spring 2004

Security Levels “Share-wide”: authorized clients

can access any file under that share.

“File-level”: before accessing any file, client needs to be authenticated; in fact, client authenticated once and uses UID for future accesses.

Page 49: Network Administration

Spring 2004

More servers: DNS and Mail

Page 50: Network Administration

Spring 2004

Domain Name System (DNS) Basic function: translation of

names (ASCII strings) to network (IP) addresses and vice-versa.

Example: zephyr.isi.edu <-> 128.9.160.160

Page 51: Network Administration

Spring 2004

History Original approach (ARPANET, 1970’s):

File hosts.txt listed all hosts and their IP addresses.

Every night every host fetches file from central repository.

OK for a few hundred hosts. Scalability?

File size. Centrally managed.

Page 52: Network Administration

Spring 2004

DNS Hierarchical name space. Distributed database. RFCs 1034 and 1035.

Page 53: Network Administration

Spring 2004

How is it used? Client-server model.

Client DNS (running on client hosts), or resolver.

Application calls resolver with name. Resolver contacts local DNS server

(using UDP) passing the name. Server returns corresponding IP

address.

Page 54: Network Administration

Spring 2004

Namespace Flat versus hierarchical. Flat:

Sequence of characters with no structure. Short, convenient names. But, doesn’t scale! Why?

Unique names. Hard to decentralize.

Hierarchical: Name space partitioned and decentralized. Portions delegated to different authorities.

Page 55: Network Administration

Spring 2004

DNS Name Space Tree-based hierarchy.

int com edu gov mil org net us ca …

usc

cs ee

ibm

eng sales

Page 56: Network Administration

Spring 2004

Name Space Structure Top-level domains:

Generic. Countries.

Leaf domains: no sub-domains. In practice all US organizations are

under a generic domain, while everything outside the US is under the corresponding country domain.

Page 57: Network Administration

Spring 2004

DNS Names Domain names:

Concatenation of all domain names starting from its own all the way to the root separated by “.”.

Refers to a tree node and all names under it.

Case insensitive. Components up to 63 characters. Full name less than 255 characters.

Page 58: Network Administration

Spring 2004

Name Space Management Domains are autonomous.

Organizational boundaries. Each domain manages its own name

space independently of other domains. Delegation:

When creating new domain: register with parent domain.

For name uniqueness. For name resolution.

Page 59: Network Administration

Spring 2004

Resource Records Entry in the DNS database. Several types of entries or RRs. Example: RR “A” contains IP address. Name <-> several resource records. RR format: five-tuple.

Name. TTL (in seconds). Class (usually “IN” for Internet info). Type: type of RR. Value.

Page 60: Network Administration

Spring 2004

RR Types 1 SOA: start of authority.

Marks beginning of zone’s database. Provides general info about the zone: e-mail

address of admin, default TTL, etc. A: address.

Contains 32-bit IP address. Single name <-> several A RRs.

MX: mail exchange. Name of mail server for this domain.

Page 61: Network Administration

Spring 2004

RR Types 2 NS: name server.

Name of name server for this domain. CNAME: canonical name.

Alias. HINFO: host description.

Provides information about host, e.g., CPU type, OS, etc.

TXT: arbitrary string of characters. Generic description of the domain, where it

is located, etc.

Page 62: Network Administration

Spring 2004

Name Servers Entire database in a single name server.

Practical? Why?

DNS database is partitioned into zones. Each zone contains part of the DNS tree. Zone <-> name server.

Each zone may be served by more than 1 server.

A server may serve multiple zones. Primary and secondary name servers.

Page 63: Network Administration

Spring 2004

Name Resolution 1 Application wants to resolve name. Resolver sends query to local name server.

Resolver configured with list of local name servers.

Select servers in round-robin fashion. If name is local, local name server returns

matching authoritative RRs. Authoritative RR comes from authority

managing the RR and is always correct. Cached RRs may be out of date.

Page 64: Network Administration

Spring 2004

Name Resolution 2 If information not available locally

(not even cached), local NS will have to ask someone else. It asks the server of the top-level

domain of the name requested.

Page 65: Network Administration

Spring 2004

Recursive Resolution Recursive query:

Each server that doesn’t have info forwards it to someone else.

Response finds its way back. Alternative: iterative resolution

Name server not able to resolve query, sends back the name of the next server to try.

Some servers use this method. More control for clients.

Page 66: Network Administration

Spring 2004

Example Suppose resolver on flits.cs.vu.nl wants to

resolve linda.cs.yale.edu. Local NS, cs.vu.nl, gets queried but cannot resolve

it. It then contacts .edu server. .edu server forwards query to yale.edu server. yale.edu contacts cs.yale.edu, which has the

authoritative RR. Response finds its way back to originator. cs.vu.nl caches this info.

Not authoritative (since may be out-of-date). RR TTL determines how long RR should be cached.

Page 67: Network Administration

Spring 2004

Caching Name servers cache recent requests

and corresponding mappings. Also, cache server that provided

mapping. Cached information is non-

authoritative. Clients may choose to use them or go

to authoritative server for fresh copy.

Page 68: Network Administration

Spring 2004

Cache consistency TTL: how long cached copy is valid. Specified by original server. May be different for each object. Long versus short TTLs.

Page 69: Network Administration

Spring 2004

More details… RFC 1034 and 1035.

Page 70: Network Administration

Spring 2004

Electronic Mail Non-interactive.

Deferred mail (e.g., destination temporarily unavailable).

Spooling: Message delivery as background

activity. Mail spool: temporary storage area

for outgoing mail.

Page 71: Network Administration

Spring 2004

Mail system

Userinterface

Usersends mail

Userreads mail

Outgoingmailspool

Mailboxes incomingmail

Client(send)

Server(receive)

TCPconnection(outgoing)

TCPconnection(incoming)

Page 72: Network Administration

Spring 2004

Observations When user sends mail, message

stored is system spool area. Client transfer runs on background. Initiates transfer to remote

machine. If transfer succeeds, local copy of

message removed; otherwise, tries again later (30 min) for a maximum interval (3 days).

Page 73: Network Administration

Spring 2004

Mail alias expansion Mapping of e-mail identifiers to mail

addresses. Mail interface consults local alias database

and performs mapping before passing message to outgoing mail spool.

One-to-many (e.g., mailing lists) and many-to-one (e.g., multiple ways to refer to a single user) mapping.

Incoming mail also goes through alias expansion before delivery.

Page 74: Network Administration

Spring 2004

SMTP Simple Mail Transfer Protocol How messages are transferred over

a TCP/IP internet. Defines commands used to

exchange mail between mail clients and servers.

Problems reported to user by e-mail.

Page 75: Network Administration

Spring 2004

Example SMTP exchangeUser [email protected] sends message to jones, green, and [email protected].

S: 220 beta.gov readyC: Helo alpha.eduS: 250 beta.govC: MAIL FROM [email protected]: 250 OKC: RCPT TO: [email protected]: 250 OKC: RCPT TO: [email protected]: 550 no such userC: DATA …

Page 76: Network Administration

Spring 2004

Mail retrieval SMTP implies server is always

listening. What about machines with

intermittent Internet access? 2-stage delivery: message delivered to

user permanent mailbox; then user connects to retrieve messages.

User needs protocol to retrieve messages from “permanent” mailboxes.

Page 77: Network Administration

Spring 2004

Post Office Protocol version 3 POP3. User invokes POP3 client; connects to

POP3 server through TCP. Requires authentication (user id and

passwd). Commands to retrieve and delete

messages from permanent mailbox. Mail server needs to run SMTP and POPP3.

Mailbox a shared data.

Page 78: Network Administration

Spring 2004

More details… RFC 821 and 822 specify SMTP and

its message formats.