DOCSLIB.ORG

12. Inetd, RPC/Portmapper, NFS Table of Contents 12

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
12. Inetd, RPC/Portmapper, NFS Table of Contents 12 12. Inetd, RPC/Portmapper, NFS Table of Contents 12. INETD, RPC/PORTMAPPER, NFS......................................... 1 This is a miscellaneous topic section which will briefly 12.1 INETD -THE SUPER DAEMON.................................................. 3 survey some of the application-support functionality needed 12.1.1 Configuring inetd ............................................................ 4 in network operating systems. We will concentrate on Unix, 12.1.2 When Not To Use Inetd.................................................... 5 but you should be aware that some of these features (e.g. 12.1.3 Programming Servers for inetd ....................................... 6 NFS) are available on personal computer operating systems 12.2 RPC ........................................................................................ 7 so that they can interact with Unix systems. 12.2.1 The Portmapper............................................................... 9 Readings: 12.2.2 Configuring the Portmapper ......................................... 10 12.2.3 Other RPC Issues .......................................................... 11 Sections 9.1 - 9.3 of [Carl-Mitchell93]. These three 12.3 NFS ...................................................................................... 14 subsections provide a nice, brief introduction to these three 12.3.1 NFS Daemons................................................................ 15 topics. Optionally, you may additionally want to read the 12.3.2 Exporting....................................................................... 16 later subsections of this same chapter which cover print 12.3.3 Mounting ....................................................................... 17 spooling, netnews, anonymous FTP, rlogin/rshell/rcp, and 12.3.4 NFS Security.................................................................. 20 syslog. 12.4 REFERENCES ......................................................................... 21 Optionally, you may be interested in: • A whole book published by O’Reilly on managing NFS and NIS mentioned in this section’s reference subsection. • [Stevens94] has a section on managing NFS, as does [Nemeth95] • More information about NFS is also presented in Cmpt 401. See for instance, the web page mentioned in [Atikins]. • Finally, Sun has lots of online NFS information at http://www.sun.com/software/white-papers/wp-nfs Copyright 1997 by Russ Tront Page 12-1 Copyright 1997 by Russ Tront Page 12-2 12.1 Inetd - The Super Daemon 12.1.1 Configuring inetd If a server is started at boot time, it constantly takes up Before inetd will listen on behalf of a server, you must RAM and other resources in a computer. This is terribly inform it that it should do so. This is set by a line in the file wasteful if the server will never once be called that day! /etc/inetd.conf. e.g. In addition, because the start up code for most servers are ftp stream tcp nowait nobody /bin/in.ftpd in.ftpd similar, it is wasteful to have the same (open socket and comsat dgram udp wait root /bin/in.comsat in.comsat bind) code for each different running server in RAM all the The first column indicates the name of the port. Service time. names to port mappings are stored in the file /etc/services. Unix has adopted the concept of a super server which sits This file is really just the port numbers well known to the waiting with sockets open on all ports for which servers machine. The next two columns indicate the protocol type have been specified in the inetd.conf file. If a packet comes and name. The wait column indicates whether inetd should in for, say, ftp (which is supposed to be listening on port 21), accept another connection or packet before the last has been the packet is actually detected by inetd using select(). completely handled (i.e. concurrency or serialization). ‘Wait’ Inetd, in turn, brings in ftpd from disk and starts it up. mode is generally necessary for UDP servers. If the packet was for a TCP port, it performs an accept() on The nobody/root column indicates the uid or uid name that the appropriate socket which creates a second socket which the spawned process and server should run as. Ftp is not inetd can give to ftpd to handle the connection. very safe, so it should not run as root. I’m not sure why the full path to the server and the server name have to both be Inetd forks and the I/O descriptor of the socket is copied then stated. over to the child’s I/O descriptor 0 (stdin), 1 (stdout), and 2 (stderr). The child process transfers control using exec() to the actual server. This allows an actual server to be run which don’t know about sockets but instead uses read() and write() to stdin and stdout. When the server completes, a SIGCLD signal is generated which the child inetd has been wait()’ing for. Note that UDP servers must run slightly differently, using ‘wait’ mode, in order to avoid a race condition that could wrongly repeatedly fork children into existence. Copyright 1997 by Russ Tront Page 12-3 Copyright 1997 by Russ Tront Page 12-4 12.1.2 When Not To Use Inetd 12.1.3 Programming Servers for inetd inetd is not very suitable in the following cases: Generally, servers started by inetd must be non-standard, as they needn’t perform a call to socket(), bind(), and if • When fast server response is needed. In real time and connection-oriented, to listen(). This is an advantage other applications, you often cannot wait for the server to though as this code need only be in RAM in one place, inside be loaded from disk. inetd. Interestingly, it also allows even OS command line • When a server must maintain state in RAM between commands to be turned into a inetd-parented server. executions. DNS, for instance, maintains data in a RAM One of the few references I have found which contain cache which would be lost if the ‘named’ daemon was information on actually programming a server to work with halted after it had finished servicing a request. inetd is [Stevens98]. I suspect that some of the big OS • When a service is frequently used and has high (or slow) manufacturers would also have manuals that cover this start up overhead. For instance a server that not only topic. must be read in from disk, but once running itself must read in some configuration data of its own from disk. • When Unix rather than Internet domain sockets are used. I.e. The server must use a transport layer, even if it is just communicating with itself using the loopback/localhost address. Copyright 1997 by Russ Tront Page 12-5 Copyright 1997 by Russ Tront Page 12-6 procedure into a packet, and sends them to port 111 on the 12.2 RPC destination computer. Programmers are very used to the procedure call paradigm. On the remote computer, a process must be started which But procedures calls are usually to functions that are in acts as a proxy for the calling function. It is sometimes RAM on the same computer as is the caller. More correctly, called a driver. It’s job is to de-marshal the arriving are in the same address space (vs. a different process’s VM parameters, get the function to be called into RAM, and address space). make the actual call. Because of the familiar and convenient paradigm, the concept of ‘remote procedure call’ was created. This concept Client will become extremely important in the future because of the deployment of distributed systems using Sun RPC standard, and more recently of component software (where the component often runs in its own process/DLL), and Stub Driver distributed components (e.g. Microsoft DCOM, and Java Remote Method Invocation). For information on Sun RPC standard (which us used on personal computers too) see: Called Function http://www.internic.net/rfc/rfc1057.txt Comm. Medium For information on Microsoft DCOM see: http://www.microsoft.com/com/dcom.htm Note that in some brands of RPC technology the driver is And for information on Java RMI, see called a ‘proxy’ as it is standing in for the client/caller, while http://java.sun.com/marketing/collateral/javarmi.html in other brands the stub that is called a proxy (because it is The basic concept is that you call a remote procedure standing in for the called function). exactly as you would a local procedure (with some restrictions to be discussed later). In order to implement such a procedure call, the caller actually links to a local stub function. The stub function has the same name, parameter list, and return type as the remote procedure. The stub ‘marshals’ the parameters headed toward the remote Copyright 1997 by Russ Tront Page 12-7 Copyright 1997 by Russ Tront Page 12-8 12.2.1 The Portmapper 12.2.2 Configuring the Portmapper For standard Unix function calls, there is a kind of ‘super The portmapper must be started before any RPC driver driver’ that monitors port 111. It is called the Portmapper. daemons. Since there are zillions of possible functions that could be The portmapper can be configured to support indirect calls, called, the concept of a well know port for each of them does where the client is not returned the port number of where to not make sense. Instead, all initial calls are typically sent call for the actual function’s daemon, but the call is actually to port 111 where the portmapper is waiting. Each actual forwarded by the portmapper to the correct function at the driver process has typically pre-registered the port number correct port, and somehow the function return gets back to that it got randomly bound to with the portmapper. The the caller in such a way that it realizes the actual port that portmapper thus responds to callers with the actual (poorly function is available through for future calls. known) port number where the actual driver process for that function can be reached. To broadcast a message to find out which machines in a network support a particular service, you can use: You can see what driver processes the portmapper is able to handle by issuing the rpcinfo -p command.
Load more

Recommended publications
  • The Linux Kernel Module Programming Guide
    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
    [Show full text]
  • CIS IBM AIX 7.1 Benchmark V1.1.0 - 09-20-2013
    CIS IBM AIX 7.1 Benchmark v1.1.0 - 09-20-2013 http://benchmarks.cisecurity.org The CIS Security Benchmarks division provides consensus-oriented information security products, services, tools, metrics, suggestions, and recommendations (the “SB Products”) as a public service to Internet users worldwide. Downloading or using SB Products in any way signifies and confirms your acceptance of and your binding agreement to these CIS Security Benchmarks Terms of Use. CIS SECURITY BENCHMARKS TERMS OF USE BOTH CIS SECURITY BENCHMARKS DIVISION MEMBERS AND NON-MEMBERS MAY: Download, install, and use each of the SB Products on a single computer, and/or Print one or more copies of any SB Product that is in a .txt, .pdf, .doc, .mcw, or .rtf format, but only if each such copy is printed in its entirety and is kept intact, including without limitation the text of these CIS Security Benchmarks Terms of Use. UNDER THE FOLLOWING TERMS AND CONDITIONS: SB Products Provided As Is. CIS is providing the SB Products “as is” and “as available” without: (1) any representations, warranties, or covenants of any kind whatsoever (including the absence of any warranty regarding: (a) the effect or lack of effect of any SB Product on the operation or the security of any network, system, software, hardware, or any component of any of them, and (b) the accuracy, utility, reliability, timeliness, or completeness of any SB Product); or (2) the responsibility to make or notify you of any corrections, updates, upgrades, or fixes. Intellectual Property and Rights Reserved. You are not acquiring any title or ownership rights in or to any SB Product, and full title and all ownership rights to the SB Products remain the exclusive property of CIS.
    [Show full text]
  • Autoconf.Pdf
    Autoconf Creating Automatic Configuration Scripts for version 2.66, 2 July 2010 David MacKenzie Ben Elliston Akim Demaille This manual (2 July 2010) is for GNU Autoconf (version 2.66), a package for creating scripts to configure source code packages using templates and an M4 macro package. Copyright c 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being \A GNU Manual," and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled \GNU Free Documentation License." (a) The FSF's Back-Cover Text is: \You have the freedom to copy and modify this GNU manual. Buying copies from the FSF supports it in developing GNU and promoting software freedom." i Table of Contents 1 Introduction::::::::::::::::::::::::::::::::::::: 1 2 The GNU Build System:::::::::::::::::::::::: 3 2.1 Automake:::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.2 Gnulib ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.3 Libtool::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 2.4 Pointers:::::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 3 Making configure Scripts :::::::::::::::::::::: 5 3.1 Writing `configure.ac' ::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Absolute BSD—The Ultimate Guide to Freebsd Table of Contents Absolute BSD—The Ultimate Guide to Freebsd
    Absolute BSD—The Ultimate Guide to FreeBSD Table of Contents Absolute BSD—The Ultimate Guide to FreeBSD............................................................................1 Dedication..........................................................................................................................................3 Foreword............................................................................................................................................4 Introduction........................................................................................................................................5 What Is FreeBSD?...................................................................................................................5 How Did FreeBSD Get Here?..................................................................................................5 The BSD License: BSD Goes Public.......................................................................................6 The Birth of Modern FreeBSD.................................................................................................6 FreeBSD Development............................................................................................................7 Committers.........................................................................................................................7 Contributors........................................................................................................................8 Users..................................................................................................................................8
    [Show full text]
  • Daemon Threads
    Daemon threads Your operating system has various threads that provide services to user threads. That’s their sole purpose: to serve user threads. The term originated with the Unix operating system, but most operating systems have them in one form or another, with slightly differing properties. Examples are: • In Unix, crond is job scheduler, running jobs in the background. Line printer daemon lpd manages printer spooling. • In Windows systems, daemons are called Windows services. One such is Prefetch-and-Superfetch, which caches frequently used files and other components to RAM. The DNS Client resolves domain names to IP addresses. • In Java, the garbage collector is a daemon, continuously finding objects that cannot be reached from the Java program and putting the memory they occupy on a “free list” so the memory can be used for some other purpose. We won’t be writing Java programs that use daemon threads. (Look at the next page for a realistic use of a daemon thread.) Nevertheless, a basic understanding of daemons, including where the word came from, is useful. The basic property of a Java daemon thread In Java, suppose your main-program thread is named t. Suppose t creates and starts threads t1, t2, and t3. Suppose also that it has made t3 a daemon (we show how to do this later). Here is the basic difference be- tween t3 and the other threads: When thread t, t1, and t2 die (i.e. complete method run()), daemon thread t3 is killed. Thus, as long as one normal thread is alive, daemon threads stay alive.
    [Show full text]
  • Freebsd Command Reference
    FreeBSD command reference Command structure Each line you type at the Unix shell consists of a command optionally followed by some arguments , e.g. ls -l /etc/passwd | | | cmd arg1 arg2 Almost all commands are just programs in the filesystem, e.g. "ls" is actually /bin/ls. A few are built- in to the shell. All commands and filenames are case-sensitive. Unless told otherwise, the command will run in the "foreground" - that is, you won't be returned to the shell prompt until it has finished. You can press Ctrl + C to terminate it. Colour code command [args...] Command which shows information command [args...] Command which modifies your current session or system settings, but changes will be lost when you exit your shell or reboot command [args...] Command which permanently affects the state of your system Getting out of trouble ^C (Ctrl-C) Terminate the current command ^U (Ctrl-U) Clear to start of line reset Reset terminal settings. If in xterm, try Ctrl+Middle mouse button stty sane and select "Do Full Reset" exit Exit from the shell logout ESC :q! ENTER Quit from vi without saving Finding documentation man cmd Show manual page for command "cmd". If a page with the same man 5 cmd name exists in multiple sections, you can give the section number, man -a cmd or -a to show pages from all sections. man -k str Search for string"str" in the manual index man hier Description of directory structure cd /usr/share/doc; ls Browse system documentation and examples. Note especially cd /usr/share/examples; ls /usr/share/doc/en/books/handbook/index.html cd /usr/local/share/doc; ls Browse package documentation and examples cd /usr/local/share/examples On the web: www.freebsd.org Includes handbook, searchable mailing list archives System status Alt-F1 ..
    [Show full text]
  • Mengenal Sistim Operasi *BSD
    Mengenal Sistim Operasi *BSD Ada banyak sekali tulisan-tulisan yang membahas tentang BSD, baik tulisan mengenai sejarah, system administrasi, sampai penggunaan BSD kepada end-user sebagai desktop. Tulisan ini memperkenalkan BSD sebagai alternatif lain dari Linux untuk memenuhi kebutuhan akan UNIX-like operating system di Indonesia. Dalam tulisan ini pula, dibahas mengenai beberapa hal yang membedakan antara Linux dan BSD, namun tidak memutuskan mana yang paling baik, karena untuk menentukan mana operating system yang paling baik digunakan adalah Anda sendiri. Daftar Isi 1. Sejarah 2. Distribusi Varian BSD 3. Model Pengembangan 4. Integrasi System 5. Software-software di BSD 6. System Administrasi 7. File System 8. Lain-lain 9. Kesimpulan Sejarah Hampir semua orang telah mendengar Linux saat ini. Namun apa itu BSD? BSD adalah singkatan dari Berkeley Software Distribution. BSD pertama kali dibangun dan dikembangkan oleh Computer System Research Group (CSRG) di University of California at Berkeley (UCB), BSD pertama kali keluar pada akhir 1977 sebagai paket tambahan dan patch dari AT&T UNIX version 6, yang mana waktu itu beroperasi pada mesin PDP-11 minicomputer. BSD pada akhirnya banyak memberikan kontribusi berharga pada pengembangan UNIX secara umum. Ada banyak fitur yang pertama kali diperkenalkan oleh BSD dan beberapa diadopsi dari AT&T dan vendor-vendor lainnya. BSD dibuat, dikembangkan, dan digunakan secara BEBAS sebagai perlawanan terhadap lisensi UNIX yang dimiliki oleh AT&T dan oleh karena itu BSD mempunyai lisensi tersendiri yang memungkinkan setiap orang bebas melakukan pengembangan, dan menggunakan source code BSD. Pada tahun 1993, 4.4BSD dirilis sebagai sebuah Operating System yang utuh. Untuk sejarah lengkap BSD di CSRG, mulai sejarah dari jaman kuda, motivasi orang-orang yang pertama kali mengerjakannya, sampai perseteruan lisensi dan hak cipta dengan AT&T, saya mereferensikan Anda untuk membaca tulisan yang dibuat oleh Kirk McKusick, “Twenty Years of Berkeley Unix“.
    [Show full text]
  • Understanding the Linux Kernel, 3Rd Edition by Daniel P
    1 Understanding the Linux Kernel, 3rd Edition By Daniel P. Bovet, Marco Cesati ............................................... Publisher: O'Reilly Pub Date: November 2005 ISBN: 0-596-00565-2 Pages: 942 Table of Contents | Index In order to thoroughly understand what makes Linux tick and why it works so well on a wide variety of systems, you need to delve deep into the heart of the kernel. The kernel handles all interactions between the CPU and the external world, and determines which programs will share processor time, in what order. It manages limited memory so well that hundreds of processes can share the system efficiently, and expertly organizes data transfers so that the CPU isn't kept waiting any longer than necessary for the relatively slow disks. The third edition of Understanding the Linux Kernel takes you on a guided tour of the most significant data structures, algorithms, and programming tricks used in the kernel. Probing beyond superficial features, the authors offer valuable insights to people who want to know how things really work inside their machine. Important Intel-specific features are discussed. Relevant segments of code are dissected line by line. But the book covers more than just the functioning of the code; it explains the theoretical underpinnings of why Linux does things the way it does. This edition of the book covers Version 2.6, which has seen significant changes to nearly every kernel subsystem, particularly in the areas of memory management and block devices. The book focuses on the following topics: • Memory management, including file buffering, process swapping, and Direct memory Access (DMA) • The Virtual Filesystem layer and the Second and Third Extended Filesystems • Process creation and scheduling • Signals, interrupts, and the essential interfaces to device drivers • Timing • Synchronization within the kernel • Interprocess Communication (IPC) • Program execution Understanding the Linux Kernel will acquaint you with all the inner workings of Linux, but it's more than just an academic exercise.
    [Show full text]
  • Daemon Management Under Systemd ZBIGNIEWSYSADMIN JĘDRZEJEWSKI-SZMEK and JÓHANN B
    Daemon Management Under Systemd ZBIGNIEWSYSADMIN JĘDRZEJEWSKI-SZMEK AND JÓHANN B. GUÐMUNDSSON Zbigniew Jędrzejewski-Szmek he systemd project is the basic user-space building block used to works in a mixed experimental- construct a modern Linux OS. The main daemon, systemd, is the first computational neuroscience lab process started by the kernel, and it brings up the system and acts as and writes stochastic simulators T and programs for the analysis a service manager. This article shows how to start a daemon under systemd, of experimental data. In his free time he works describes the supervision and management capabilities that systemd pro- on systemd and the Fedora Linux distribution. vides, and shows how they can be applied to turn a simple application into [email protected] a robust and secure daemon. It is a common misconception that systemd is somehow limited to desktop distributions. This is hardly true; similarly to Jóhann B. Guðmundsson, the Linux kernel, systemd supports and is used on servers and desktops, but Penguin Farmer, IT Fireman, Archer, Enduro Rider, Viking- it is also in the cloud and extends all the way down to embedded devices. In Reenactor, and general general it tries to be as portable as the kernel. It is now the default on new insignificant being in an installations in Debian, Ubuntu, Fedora/RHEL/CentOS, OpenSUSE/SUSE, insignificant world, living in the middle of the Arch, Tizen, and various derivatives. North Atlantic on an erupting rock on top of the world who has done a thing or two in Systemd refers both to the system manager and to the project as a whole.
    [Show full text]
  • Bootstrap Protocol, BOOTP, Is the Recommended Way to Establish Communications from the Host to the Printer in an Internet Protocol Environment
    BOOTP Bootstrap protocol, BOOTP, is the recommended way to establish communications from the host to the printer in an internet protocol environment. BOOTP obtains booting data from the bootptab file. With the proper information stored in the bootptab file, the printer can find its own name and IP address and boot from the network without any intervention, even for a first time boot. 1. Verify that the bootpd and bootptab files are in the correct directories: UNIX: /etc or /usr/etc directory OS/2: \TCPIP\ETC (for bootptab) and \TCPIP\BIN (for bootpd) LAN Server: MPTN\ETC (for bootptab) and \MPTN\BIN (for bootpd) Type: ls bootp* 2. Edit the hosts file to add the printer internet addresses and names: 128.07.60.30 P340-mktg 128.07.60.31 P340-sales For OS/2, use the TCP/IP Configuration Notebook under the Services tab to add the printer internet addresses and names. 3. Some UNIX hosts may require an explicit update to the arp table to add the new entries. This command is host-specific; check your host documentation for details. arp -s ether P340-mktg 08:00:11:01:00:45 arp -s ether P340-sales 08:00:11:01:00:46 The ether switch indicates that you are providing an Ethernet address. 4. Set up the bootptab file. 5. Start or restart the inetd or bootpd daemon. For OS/2 Warp, LAN Server 4.0, and UNIX, use the bootpd daemon. Here is a sample bootptab file; check your host system documentation to see which fields your implementation of BOOTP supports.
    [Show full text]
  • Intel® Command Line Interface Features and Benefits
    Intel® Command Line Interface User Guide IntelIntel®®®® CoCoCommandCo mmand Line Interface Version 3.03.03.0 Legal Information INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS FOR THE PURPOSE OF SUPPORTING INTEL DEVELOPED SERVER BOARDS AND SYSTEMS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
    [Show full text]
  • Appendix D: Summary of Samba Daemons and Commands
    ,appd.28002 Page 359 Friday, November 19, 1999 3:31 PM Appendix D D Summary of Samba Daemons and Commands This appendix is a reference listing of command-line options and other informa- tion to help you use the executables that come with Samba distribution. Samba Distribution Programs The following sections provide information about the command-line parameters for Samba programs. smbd The smbd program provides Samba’s file and printer services, using one TCP/IP stream and one daemon per client. It is controlled from the default configuration file, samba_dir/lib/smb.conf, and can be overridden by command-line options. The configuration file is automatically re-evaluated every minute. If it has changed, most new options are immediately effective. You can force Samba to immediately reload the configuration file if you send a SIGHUP to smbd. Reloading the configu- ration file, however, will not affect any clients that are already connected. To escape this “grandfather” configuration, a client would need to disconnect and reconnect, or the server itself would have to be restarted, forcing all clients to reconnect. Other signals To shut down a smbd process, send it the termination signal SIGTERM (-15) which allows it to die gracefully instead of a SIGKILL (-9). To increment the debug log- ging level of smbd at runtime, send the program a SIGUSR1 signal. To decrement it at runtime, send the program a SIGUSR2 signal. 359 ,appd.28002 Page 360 Friday, November 19, 1999 3:31 PM 360 Appendix D: Summary of Samba Daemons and Commands Command-line options -D The smbd program is run as a daemon.
    [Show full text]