M1: New Topics in System Administration USENIX LISA 1995 Trent Hein XOR Network Engineering trent@xor.com and Evi Nemeth University of Colorado evi@colorado.edu New Topics in SA: USENIX LISA 1995 - 1 - (C) 1995 Hein & Nemeth Table of Contents *Dealing with Daemons - page 3 *Security Recovery - page 24 *Video Conferencing Tools - page 37 *Sys Admin Power Tools - page 61 New Topics in SA: USENIX LISA 1995 - 2 - (C) 1995 Hein & Nemeth New Topics in System Administration LISA 1995 Dealing with Daemons New Topics in SA: USENIX LISA 1995 - 3 - (C) 1995 Hein & Nemeth Daemons *A "daemon" is an attendant spirit that influences one's character or personality. *Daemons aren't good or evil, they are creatures of independent thought and will *Daemons were originally used in CTSS (early '60s) and Multics *Today, daemons provide essential net work services to the UNIX platform New Topics in SA: USENIX LISA 1995 - 4 - (C) 1995 Hein & Nemeth Daemons - 2 *Originally (the BSD 2.9/4.2 era) every possible service had a daemon running at all times, just waiting to serve you *Especially in the small-memoried PDP11 series, this became an unreason able system load *Most services these days are handled by inetd *Some services are still independent *Learning to use daemons is an impor tant part of the security, performance, and functionality of your system. New Topics in SA: USENIX LISA 1995 - 5 - (C) 1995 Hein & Nemeth init - The Mother of All Processes *init is present on all UNIX systems, and in many ways is the most important daemon *init always have a PID of 1, and is the ancester of all users processes (and most system processes) *It is responsible for reading the system startup files on book (/etc/rc*) and (on most system) forking gettys. *Inherits and does a wait() for all orphaned-but-exiting children *On SystemV-ish boxes, transitions between system run levels New Topics in SA: USENIX LISA 1995 - 6 - (C) 1995 Hein & Nemeth inetd - the Super Daemon *Manages other daemons *Starts up clients daemons when there is work for them, allows them to die after wards *Requires special modifications to the client daemon (so that they do I/O via stdin/stdout, and obtain connection infor mation via getpeername()). * Most modern daemons can be run in either mode with a flag *inetd attaches itself to network ports that it has clients for, and starts the client daemon when a connection occurs New Topics in SA: USENIX LISA 1995 - 7 - (C) 1995 Hein & Nemeth /etc/services *inetd needs 2 files to do its job correctly. */etc/services provides the map ping between ports and service name: telnet 23/tcp smtp 25/tcp tftp 69/udp finger 79/tcp pop2 110/tcp pop3 110/tcp talk 517/udp ntalk 518/udp gopher 70/tcp www 80/tcp New Topics in SA: USENIX LISA 1995 - 8 - (C) 1995 Hein & Nemeth /etc/inetd.conf *inetd.conf describes what ports to bind to and what program to execute in the event of a connection # # Internet services syntax: # # # ftp stream tcp nowait root /usr/etc/ftpd ftpd telnet stream tcp nowait root /usr/etc/telnetd telnetd pop stream tcp nowait root /chimchim/devel/popper popper *Security-conscious systems use the TCPwrapper package to log and authen ticate all connetions: talk dgram udp wait root /usr/etc/tcpdin.talkd ntalk dgram udp wait root /usr/etc/tcpdin.ntalkd *You'll need to kill and restart inetd after you've edited inetd.conf (some times, SIGHUP works). New Topics in SA: USENIX LISA 1995 - 9 - (C) 1995 Hein & Nemeth wuftpd *Available via anonymous ftp from "wuarchive.wustl.edu" in /packages/wuarchive-ftpd *"Normal" ftpd provides ftp (file transfer) access to users with accounts *Can also be configured to offer "anonymous ftp" service *Many vendors versions of ftpd have serious security holes. New Topics in SA: USENIX LISA 1995 - 10 - (C) 1995 Hein & Nemeth wuftpd - cont *wuftpd contains a number of improve ments over the "stock" version * Logging of transfers * Logging of commands * On-the-fly compression and archiving * Classification of users on type and lo cation * Per class limits * Per directory upload permissions * Restricted guest accounts * System wide and per directory mes sages. * Directory alias * Cdpath * Filename filter New Topics in SA: USENIX LISA 1995 - 11 - (C) 1995 Hein & Nemeth Example ftpaccess file loginfails 2 class local real,guest,anonymous *.domain 0.0.0.0 class remote real,guest,anonymous * limit local 20 Any /etc/msgs/msg.toomany limit remote 100 SaSu|Any1800-0600 /etc/msgs/msg.toomany limit remote 60 Any /etc/msgs/msg.toomany readme README* login readme README* cwd=* message /welcome.msg login message .message cwd=* compress yes local remote tar yes local remote # allow use of private file for SITE GROUP and SITE GPASS? private yes # passwd-check [] passwd-check rfc822 warn log commands real log transfers anonymous,real inbound,outbound shutdown /etc/shutmsg # all the following default to "yes" for everybody delete no guest,anonymous # delete permission? overwrite no guest,anonymous # overwrite permission? rename no guest,anonymous # rename permission? chmod no anonymous # chmod permission? umask no anonymous # umask permission? # specify the upload directory information upload /var/ftp * no upload /var/ftp /incoming yes root daemon 0600 dirs upload /var/ftp /bin no upload /var/ftp /etc no # directory aliases... [note, the ":" is not required] alias inc: /incoming # cdpath cdpath /incoming cdpath /pub cdpath / # path-filter... path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9_\.]*$ ^\. ^- path-filter guest /etc/pathmsg ^[-A-Za-z0-9_\.]*$ ^\. ^- # specify which group of users will be treated as "guests". guestgroup ftponly New Topics in SA: USENIX LISA 1995 - 12 - (C) 1995 Hein & Nemeth ftp caveats *Avoid allowing any directories that users can both upload and download files from -- this creates "hacker nests" * Incoming-only directories, if carefully monitored, are ok *Consider running an anonymous ftp server accessible from the outside world, and a separate one for internal use *Browse ftpd logfiles at least on a weekly (if not daily) to watch for suspicious ac tivity *If you allow "regular" ftp access from the outside world, you should only allow it via S/Key or similar one-time password authentication New Topics in SA: USENIX LISA 1995 - 13 - (C) 1995 Hein & Nemeth POP: Mail for Unreliable Hosts *PCs are "unreliable" network nodes since they are turned on and off every day *Since most PCs/Macs aren't multitask ing, most TCP/IP implementations don't accept incoming connections (normally) *Post Office Protocol (POP) solves a number of these problems * Currently POP version 3 (POP-3) * Defined by RFC-1081 *Provides access to a mail drop on a mail "server" *Clients run "user agents" which snarf mail from the POP server *Clients hand outgoing mail to an SMTP server New Topics in SA: USENIX LISA 1995 - 14 - (C) 1995 Hein & Nemeth popper *popper is a daemon that serves mail to POP (Post Office Protocol) mail clients *POP is ok for internal use. POP is NOT ok for "grabbing" mail across the Inter net or other wide-area insecure links (since it re-uses the user's password re peatedly). *Available from gatekeeper.dec.com, in the file /pub/mail/ua/misc/popper 1.831beta.tar.Z. New Topics in SA: USENIX LISA 1995 - 15 - (C) 1995 Hein & Nemeth Installing popper *Edit /etc/services and add these lines: pop 110/tcp pop2 109/tcp *Edit /etc/inetd.conf and add this line: pop stream tcp nowait root /usr/local/etc/popper popper *Copy popper into its directory cp popper /usr/local/etc/popper chmod 755 /usr/local/etc/popper *Watch out for .user.pop files in /var/spool/mail that will cause popper to refuse new requests New Topics in SA: USENIX LISA 1995 - 16 - (C) 1995 Hein & Nemeth identd *identd IDENT user identification pro tocol as specified in the RFC 1413 docu ment. *identd is a useful, but not foolproof, tool for tracking connections and security matters *Available from ftp.lysator.liu.se in the file /pub/ident/servers/pidentd 2.6.1.tar.gz *Programs such as sendmail 8.7 use identd to identify and log incoming connections Received: from labyrinth.com (barb@labyrinth.com [199.45.129.6]) by xor.com (8.6.10/8.6.10) with SMTP id RAA05252 for ; Fri, 11 Aug 1995 17:39:02 -0600 New Topics in SA: USENIX LISA 1995 - 17 - (C) 1995 Hein & Nemeth identd - cont. *Can be easily integrated into programs like fingerd, telnetd, etc. for additional logging *Not foolproof - you are trusting the sys tem administrator on the other side of the connection to have installed an "honest" identd. * Better than nothing! *Evi has a great story to tell here New Topics in SA: USENIX LISA 1995 - 18 - (C) 1995 Hein & Nemeth bootpd *bootpd provides a way for "chal lenged" network devices (diskless clients, printers, UTP hubs, etc.) to get initial boot information from the network. *Use the bootp protocol .. an RFC stan dard, unlike some vendor's alternatives *Available from ncaster.andrew.cmu.edu in the file /pub/bootp2.2.tar.Z. *Uses /etc/bootptab as its configuration file New Topics in SA: USENIX LISA 1995 - 19 - (C) 1995 Hein & Nemeth /etc/bootptab example # # Legend: # # first field -- hostname # (may be full domain name) # # hd -- home directory # bf -- bootfile # cs -- cookie servers # ds -- domain name servers # gw -- gateways # ha -- hardware address # ht -- hardware type # im -- impress servers # ip -- host IP address # lg -- log servers # lp -- LPR servers # ns -- IEN-116 name servers # rl -- resource location protocol servers # sm -- subnet mask # tc -- template host (points to similar host entry) # to -- time offset (seconds) # ts -- time servers # chip-lw:\ :ht=ether:\ :ha=080009578611:\ :sm=255.255.255.0:\ :lg=192.108.21.1:\ :hn:\ :ip=192.108.21.250:\ :T144="hpnp/chip-lw.cfg":\ New Topics in SA: USENIX LISA 1995 - 20 - (C) 1995 Hein & Nemeth What is NTP? * Network time protocol described by David L. Mills in RFC 1129 * Enables synchronization of all com puter clocks in a large diverse Internet environment with widely varying net work and system speeds * Real-life performance data shows ac curacy within a few tens of mil liseconds for most of the Internet * Accurate, reliable network time is necessary for many applications in volving distributed resources * UNIX file timestamps (NFS) * Debugging * Financial/legal transactions, significant event timestamping New Topics in SA: USENIX LISA 1995 - 21 - (C) 1995 Hein & Nemeth NTP Machine Organization * Some machines actually have UTC clocks (WWVB, WWV, GPS) * Machines comprise a tree hierarchy based on distance from machines with real UTC clocks * Tree level is called stratum (stra tum 1 members have UTC clocks) * Machines at same stratum can be peers * Machines at higher stratum can be servers * Machines at lower stratum can be clients * If you are not on Internet, you must get an accurate clock or designate one machine as `accurate' and keep it that way New Topics in SA: USENIX LISA 1995 - 22 - (C) 1995 Hein & Nemeth Configuring xntpd * The file contains the configuration in formation for xntpd * ntp.conf driftfile /etc/ntp.drift # Give us a master and peers server 129.252.1.3 # promulgate1 peer 129.252.321.10 # lucifer New Topics in SA: USENIX LISA 1995 - 23 - (C) 1995 Hein & Nemeth New Topics in System Administration LISA 1995 Security Disaster Recovery New Topics in SA: USENIX LISA 1995 - 24 - (C) 1995 Hein & Nemeth Intro *A site security plan is now part of con necting to the Internet just like getting keys when you buy a house *The November 3, 1988 virus (Robert Morris Jr.) first brought Internet security to the nightly news. *Mitnick case last month (where 20,000+ VISA/MC cards accounts were comprom ised) hit the media hard *SATAN (Security Administrator Tool for Analyzing Networks) was released April 5 New Topics in SA: USENIX LISA 1995 - 25 - (C) 1995 Hein & Nemeth How is a site vulnerable *Poorly chosen passwords and weak security policies (such as accounts with no passwords at all) are the number one cause of breakins. *Bugs and "backdoors" in common software packages may be exploited without your knowledge *Password "sniffing" on the backbone may let your password fall into the hands of the wrong party *Poorly maintained Internet Service Pro viders are feeding grounds for crackers looking to read your email, or sniff your packets New Topics in SA: USENIX LISA 1995 - 26 - (C) 1995 Hein & Nemeth What might happen if you are compromised *Corporate and private "secrets" now known to the world * Business plans * Proprietary concepts * Financial information *Destruction of crucial data * Projects * Software * Data *Large amount of time spent on recovery * Restore copies of previous system from backups * Fortify security measures * "Damage control" on information that leaked out New Topics in SA: USENIX LISA 1995 - 27 - (C) 1995 Hein & Nemeth What can a site do to protect themselves *Implement a comprehensive site securi ty policy from day #1 * Use of passwords * Use of accounts * Handling of online data (should it be encrypted?) * Keep mission critical data away from the outside network (physi cally, if necessary) *Educate users on the security policy and its importance *Install packet filters and "firewalls" New Topics in SA: USENIX LISA 1995 - 28 - (C) 1995 Hein & Nemeth What is a "firewall" *Two types of firewalls * Packet filtering * Software *Packet filtering firewall is like a hard candy outside * Blocks most traffic from the outside world to undesired services *Software firewall can provide hard can dy center * Allow access only to specific services/users * One-time passwords * Alerts system administrator of poten tial problems New Topics in SA: USENIX LISA 1995 - 29 - (C) 1995 Hein & Nemeth Safe enough? *It is possible to connect to the Internet and be reasonably "safe" * But it takes work *Both software and hardware "firewalls" are necessary *Buy a good book on the subject (_Firewalls and Internet Security_ by Cheswick & Bellovin) or hire a profes sional *If you hire someone, take the time to learn what they're doing and why. You need to understand what is protecting your company from outside intruders New Topics in SA: USENIX LISA 1995 - 30 - (C) 1995 Hein & Nemeth That Dreaded Day *Some day, at the worst possible time, you will discover that despite all of your security precautions, firewalls, vigilance, etc, your site has been compromised. *You have have a plan worked out well in advance as to how a security incident should be handled at your site. *You should also get management to ap prove the plan in advance, so they do not suddenly wish they had been paying more attention in "How to tranquilize your ra bid system administrator in an emergen cy" class. *Print a dozen or so "Stay Calm. Every thing is Under Control." T-shirts and hide them in the back of your office until That Dreaded Day. New Topics in SA: USENIX LISA 1995 - 31 - (C) 1995 Hein & Nemeth The 9-step program to Security Nirvana *Step 1: Avoid Panic. * In many cases, a problem isn't noticed until hours or days after it took place. Another few hours or days won't make a bit of difference. The differ ence between a paniced response and a rational response will. * In at least 50% of recovery situations are made difficult by crucial log/tracking information destroyed during the initial panic. *Step 2: Assess appropriate level of response. * No one benefits from an over-hyped security incident. Proceed calmly. New Topics in SA: USENIX LISA 1995 - 32 - (C) 1995 Hein & Nemeth Steps - cont. *Step 3: Immediately hoard all available tracking information * Check accounting files, logs, etc. Try to determine the source of the problem *Step 4: Assess immediate corporate/data risk * Determine what crucial information (if any) "left" the company * Determine level of future risk *Step 5: If necessary/appropriate, disconnect compromised machines from the network New Topics in SA: USENIX LISA 1995 - 33 - (C) 1995 Hein & Nemeth Steps - cont. *Step 6: Stop, look, listen. With a creative colleague, and away from a key board, draw up a recovery plan on a nearby whiteboard. * Put out the fire, minimize the damage * Recover from backups * Psychological fallout * Diffs/checksums * Timestamps * Audit log * Squirreled-away files (passwords?) New Topics in SA: USENIX LISA 1995 - 34 - (C) 1995 Hein & Nemeth Steps - cont. *Step 7: Educate users and management on assessed risk and preliminary recovery strategy *Step 8: Implement recovery strategy. *Step 9: If you determine the problem to have come from outside your organiza tion, report the incident to the Computer Emergency Response Team (CERT) at +1-412-268-7090 (MILNET USERS: call SCC at 1-800-235-3155) New Topics in SA: USENIX LISA 1995 - 35 - (C) 1995 Hein & Nemeth Where to get more info *ftp.greatcircle.com - Firewalls mailing list archives. * Directory: pub/firewalls * The internet firewalls mailing list is a forum for firewall administrators and implementors. To subscribe to Firewalls, send "subscribe firewalls" in the body of a message (not on the "Subject:" line) to "Majordomo@GreatCircle.COM". *ftp.tis.com - Internet firewall toolkit and papers. * Directory: pub/firewalls *research.att.com - Papers on firewalls and breakins. * Directory: dist/internet_security *net.tamu.edu - Texas AMU security tools. * Directory: pub/security/TAMU New Topics in SA: USENIX LISA 1995 - 36 - (C) 1995 Hein & Nemeth New Topics in System Administration LISA 1995 Video Conferencing Tools New Topics in SA: USENIX LISA 1995 - 37 - (C) 1995 Hein & Nemeth The MBone *What is it? * A virtual network overlaid on the In ternet * How big? * 20,000 users * 1500 networks * 30 countries *History * 1988-90: DARTnet testbed established * 1991: First multicast audio conference * 1992: First IETF broadcast to 32 sites, 4 countries * 1993-95: ~200 networks, ~700 net works, ~1500 networks * Exponential growth, doubling time = 8 months New Topics in SA: USENIX LISA 1995 - 38 - (C) 1995 Hein & Nemeth Multicast *Uses multicast IP addresses * Each address corresponds to a conver sation, not to a host * IP numbers in the 224.0.0.1 - 239.254.254.254 range * Hosts on the MBone understand mul ticast IP packets * Hosts not on the MBone never see the multicast IP packets, they are encap sulated in a regular unicast packet *Packet types * Unicast packet: goes to 1 host * Broadcast packet: goes to all hosts on local wire * Multicast packet: goes to a group of hosts New Topics in SA: USENIX LISA 1995 - 39 - (C) 1995 Hein & Nemeth Anatomy of a Packet *Higher level protocol, encapsulated in an IP packet, encapsulated in an Ethernet frame * Native multicast, IP destination is multicast address representing a conversation * Multicast tunnel, IP destination is clueful router, higher level protocol is IP itself with IP address inside the higher level part representing multi cast conversation New Topics in SA: USENIX LISA 1995 - 40 - (C) 1995 Hein & Nemeth Tunneling D / / src --> M1 --> A ---------> B ----> M2 --> dest | \ | \ | \ | \ dest C dest \ \ dest * Assumptions * M1 and M2 understand multicast packets * A and B do not * "src" is sending to the 4 hosts la beled "dest" * Delivery Paradigm * M1 delivers multicast packet to first "dest" and encapsulates it to send to M2 via A and B * Packet is routed through A and B as any other packet to M2 would be * M1 and M2 are on the MBone; A, B, C, and D are not * Packet traverses each link at most once New Topics in SA: USENIX LISA 1995 - 41 - (C) 1995 Hein & Nemeth Multicast *User's (receivers) announce interest in a particular group *Senders send to the multicast IP ad dress of that group * Sender does not need to be a member of the group * Sender does not need to know who is in the group *Routers make it all work efficiently, mrouters *User can join a group or leave it at will New Topics in SA: USENIX LISA 1995 - 42 - (C) 1995 Hein & Nemeth Multicast *Routing protocols * DVMRP: like RIP, not hierarchical, doesn't scale * MOSPF: multicast version of OSPF, scales better * PIM: Cisco proprietary protocol that does not interoperate with DVMRP *Group protocols * IGMP: Internet group management protocol, used to form and dissolve groups New Topics in SA: USENIX LISA 1995 - 43 - (C) 1995 Hein & Nemeth Multicast Routers *Require kernel changes to do the right thing with multicast addresses *Run a daemon called mrouted to han dle multicast packets * Implements DVMRP * Use the latest version that your archi tecture supports * Very old versions did not use tun nels, but used IP source routing in stead * Old versions did not do pruning * Current version today is 3.6 *Require tunnels to reach other mrouters *Use modified version of netstat and ping that understand multicast New Topics in SA: USENIX LISA 1995 - 44 - (C) 1995 Hein & Nemeth mrouted's /etc/mrouted.conf *Four basic commands * phyint -- reverse defaults for real network interfaces * tunnel -- establish a tunnel to anoth er mrouter * The hosts at both ends of the tunnel must have it in their config files * Uses two parameters to control scope and flow: metric -- cost to send threshold -- IP ttl cutoff * cache_lifetime -- time a route is cached in the kernel, default is 5 minutes * pruning -- allows pruning to be turned off for testing New Topics in SA: USENIX LISA 1995 - 45 - (C) 1995 Hein & Nemeth Configuring /etc/mrouted.conf *Add a line for your tunnel upstream *Add lines for other folks downstream who you are willing to feed *Know your physical topology, get MBone feed from a "close" mrouter *Don't duplicate MBone traffic *Start mrouted by hand or with your rc (init.d) startup files New Topics in SA: USENIX LISA 1995 - 46 - (C) 1995 Hein & Nemeth Sample mrouted.conf File *Each mrouter is a workstation (SunOS) with kernel changes # $Id: mrouted.conf,v 1.3 1993/05/30 02:10:11 deering Exp $ # # This is the configuration file for "mrouted", an IP multicast router. # mrouted looks for it in "/etc/mrouted.conf". # # Command formats: # # phyint [disable] [metric ] [threshold ] # tunnel [srcrt] [metric ] [thresh ] # # any phyint commands MUST precede any tunnel commands # # # contacts: # paul hyder at ncar, 497-1299, hyder@niwot.scd.ucar.edu # bob bubon at uswest, 541-6627, rjbubon@advtech.uswest.com # evi nemeth at cu, 492-5385, evi@cs.colorado.edu # brian buus at xor, 440-6093, buus@xor.com # david wood at cns, 492-4905, dcmwood@westnet.net # lynda mcginley at cs, 492-2545 mcginley@cs.colorado.edu # # upstream tunnel 128.138.209.10 192.52.106.7 metric 1 threshold 64 # mbone,ncar # # downstream tunnel 128.138.209.10 192.231.90.15 metric 1 threshold 64 # mrtd,uswest tunnel 128.138.209.10 128.138.204.19 metric 1 threshold 1 # latour,here tunnel 128.138.209.10 192.108.21.1 metric 1 threshold 64 # chimchim,xor tunnel 128.138.209.10 128.138.1.19 metric 1 threshold 1 # cabal2,cns New Topics in SA: USENIX LISA 1995 - 47 - (C) 1995 Hein & Nemeth Controlling mrouted *Debugging * Supports 3 levels, -d1 (a little), -d2, and -d3 (a lot) * Uses syslog, if debugging also prints to stderr *Signals * HUP -- restarts mrouted, re-reads config file * INT, TERM -- quit gracefully * USR1, USR2 -- dumps internal routing-tables/cache-tables to /usr/tmp/mrouted.dump or /usr/tmp/mrouted.cache respectively * QUIT -- dumps routing tables to stderr if started with debugging on New Topics in SA: USENIX LISA 1995 - 48 - (C) 1995 Hein & Nemeth Control, cont *Tracing and mapping * mtrace command -- prints multicast path from src to receiver * Requires mrouted 3.3 or later * Can collect statistics too * map-mbone command -- multicast connection mapper * Identifies MBone routers accessible from a starting router * Each mrouter asks its neighbors for their list of neighbors *Statistics * mrinfo command -- shows an mrouter's neighbors and some status info about them * mstat command -- shows lots of mrouted statistics New Topics in SA: USENIX LISA 1995 - 49 - (C) 1995 Hein & Nemeth Bandwidth Requirements *500mb/sec total Internet bandwidth for the MBone * Audio needs 64 kb/sec * Video needs 128 kb/sec *T1 line to the Internet required for de cent MBone access *Experiments with ISDN in progress, look promising *Event scheduling and bandwidth reser vation done by gentleman's agreement * Regular instances of someone sending 300-500 kb/sec video of an empty office or a screen dump * Educate your MBone users, don't let the netcops catch you doing something stupid New Topics in SA: USENIX LISA 1995 - 50 - (C) 1995 Hein & Nemeth Impact on SysAdmins *Network bandwidth usage * Look for IP packets in IP with tcpdump * Locate your mrouter near the peri phery of your network * Don't trash the segments you are traversing * Don't confuse older machines (IBM RT, KSR, ...) *Read the MBone mailing lists * You are responsible for the clueful behavior of your users * Inadvertent broadcasts by mistake * Intentional broadcasts by inexperi enced users * Violations of the gentleman's agreement New Topics in SA: USENIX LISA 1995 - 51 - (C) 1995 Hein & Nemeth Uses of Multicast *Video Conferencing *USENET News Propagation *Routing updates for some protocols *Will be integrated into IPng New Topics in SA: USENIX LISA 1995 - 52 - (C) 1995 Hein & Nemeth Video Conferencing Tools *Session Managers *Audio Tools * VAT: Visual Audio Tool, Van Jacob son, Steve McCanne, LBL * NeVoT: Network Voice Tool, ???, Univ of Mass *Video Tools * nv: Network Video, Ron Frederick, Xerox PARC * vic: Van Jacobson, LBL * IMM: Univ of Hawaii, for viewing im ages *White board * wb: shared white board, VJ, LBL * wbimport: manages postscript data to be displayed, also VJ New Topics in SA: USENIX LISA 1995 - 53 - (C) 1995 Hein & Nemeth Session Managers *sd, the Session Director, provides an easy way to announce sessions and/or launch them * Written by Van Jacobson, uses tcl/tk (ftp.ee.lbl.gov) * Session control commands * Open -- join an advertised session * New -- create a new session * Edit -- change the parameters of a session you created * Delete -- stop advertising a session, delete it *mmcc, MultiMedia Conference Control, for smaller private sessions * Written by Eve Scholler and Joe Touch of ISI (ftp.isi.edu) * User invites others to join session * Can control who receives * Launches audio/video tools New Topics in SA: USENIX LISA 1995 - 54 - (C) 1995 Hein & Nemeth Vat, Visual Audio Tool *Audio teleconferencing tool *Hardware/software requirements * Workstation with a speaker and mi crophone * Requires tcl/tk and X * Supported architecture (no source dis tribution yet) *Understands lots of audio formats *Very configurable * Gain controls, for input and output * Conference or lecture modes * Mike vs. line level inputs * Mute vs. listen/broadcast *Shows packet statistics New Topics in SA: USENIX LISA 1995 - 55 - (C) 1995 Hein & Nemeth nv and vic Video Tools *nv -- Network Video conferencing tool * Written by Ron Frederick, Xerox PARC * Transmit and receive video * Transmit requires camera and frame grabber * Slow frame rate, about 4 frames/sec at 128kb/sec * Can configure transmit and receive options from control panel *vic -- VIdeo Conferencing tool * Inspired by nv, written by Steve McCanne and Van Jacobson, LBL with contributions by a host of others * Understands several video formats * Uses compression efficiently, faster than nv * Very configurable, has extensive con trol panel New Topics in SA: USENIX LISA 1995 - 56 - (C) 1995 Hein & Nemeth Whiteboard Tools *wb -- shared White Board * Written by Van Jacobson, uses tcl/tk, reliable multicast protocol * MacDraw like tool, takes typing, mouse output, postscript too * Each person gets a distinctive color or line type * Great for displaying Postscript slides * Sets a reasonable limit on the size in bytes of postscript image it will display * A bit picky on the versions/flavors of postscript it understands New Topics in SA: USENIX LISA 1995 - 57 - (C) 1995 Hein & Nemeth Whiteboard Tools, cont. *wbimport -- import Postscript for wb * The easy way to present a speakers slides * Both the speaker and the viewer can go back and forth in the slide pile *Consider a control whiteboard for any broadcast that has a wide scope * Can get feedback on the the quality of the audio/video signal going out * Can notify folks if you crash or loose your audio/video * Can display the schedule for folks browsing the sd announcements New Topics in SA: USENIX LISA 1995 - 58 - (C) 1995 Hein & Nemeth References *ftp.ee.lbl.gov/pub/conferencing and parcftp.xerox.com/pub/net-research *URL http://www.cs.ucl.ac.uk/mice/ has extensive index of multimedia stuff. *MBone Provides Audio and Video Across the Internet, Michael R. Ma cedonia and Donald P. Brutzman, Naval Postgraduate School, IEEE Computer, April, 1994, pages 30-36. This is a nice overview article, a good place to start. *MBone Frequently Asked Questions * http://www.research.att.com/mbone faq.html * http://www.cs.ucl.ac.uk/mice/faq.html New Topics in SA: USENIX LISA 1995 - 59 - (C) 1995 Hein & Nemeth References, cont. *MBone How To Documents * ftp://genome ftp.stanford.edu/pub/mbone/mbone connect *Mailing lists * rem-conf@es.net -- announcing events and issues on the MBone * mbone@isi.edu -- hierarchical list an nouncing MBone tools, for US it's mbone-na-request@isi.edu to join New Topics in SA: USENIX LISA 1995 - 60 - (C) 1995 Hein & Nemeth New Topics in SA: USENIX LISA 1995 - 61 - (C) 1995 Hein & Nemeth