DOCSLIB.ORG

Mod Wsgi Documentation Release 4.9.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Mod Wsgi Documentation Release 4.9.0 mod_wsgi Documentation Release 4.9.0 Graham Dumpleton Aug 03, 2021 Contents 1 Project Status 3 2 Security Issues 5 3 Getting Started 7 4 Requirements 9 5 Installation 11 6 Troubleshooting 13 7 User Guides 15 8 Configuration 133 9 Finding Help 159 10 Reporting Bugs 161 11 Contributing 163 12 Source Code 167 13 Release Notes 169 i ii mod_wsgi Documentation, Release 4.9.0 The mod_wsgi package implements a simple to use Apache module which can host any Python web application which supports the Python WSGI specification. The package can be installed in two different ways depending on your requirements. The first is as a traditional Apache module installed into an existing Apache installation. Following this path you will need to manually configure Apache to load mod_wsgi and pass through web requests to your WSGI application. The second way of installing mod_wsgi is to install it from PyPI using the Python pip command. This builds and installs mod_wsgi into your Python installation or virtual environment. The program mod_wsgi-express will then be available, allowing you to run up Apache with mod_wsgi from the command line with an automatically generated configuration. This approach does not require you to perform any configuration of Apache yourself. Both installation types are suitable for production deployments. The latter approach using mod_wsgi-express is the best solution if wishing to use Apache and mod_wsgi within a Docker container to host your WSGI application. It is also a better choice when using mod_wsgi during the development of your Python web application as you will be able to run it directly from your terminal. Contents 1 mod_wsgi Documentation, Release 4.9.0 2 Contents CHAPTER 1 Project Status The mod_wsgi project is still being developed and maintained. The available time of the sole developer is however limited. As a result, progress may appear to be slow. In general, the documentation is in a bit of a mess right now and somewhat outdated, so if you can’t find something then ask on the mod_wsgi mailing list for help. Also check out the Release Notes as they at least are being updated. A lot of the more recent changes are being made with the aim of making it a lot easier to deploy Apache with mod_wsgi in Docker based environments. Changes included the ability to install mod_wsgi using pip, along with an admin command called mod_wsgi-express which provides a really simple way of starting up Apache and mod_wsgi from the command line with an automatically generated configuration. 3 mod_wsgi Documentation, Release 4.9.0 4 Chapter 1. Project Status CHAPTER 2 Security Issues Due to security issues in versions of mod_wsgi up to and including version 3.4, ensure that you are using version 3.5 or later. Release notes for versions containing security related fixes are: • Version 3.5 Because many Linux distributions still ship ancient out of date versions, which are not supported, it is highly rec- ommended you avoid using packaged binary versions provided by your Linux distribution. Instead install mod_wsgi from source code, ensuring you keep up to date with the most recent version. 5 mod_wsgi Documentation, Release 4.9.0 6 Chapter 2. Security Issues CHAPTER 3 Getting Started If starting out with mod_wsgi it is recommended you start out with a simple ‘Hello World’ type application. Do not attempt to use a Python web application dependent on a web framework such as Django, Flask or Pyramid until you have got a basic ‘Hello World’ application running first. The simpler WSGI application will validate that your mod_wsgi installation is working okay and that you at least understand the basics of configuring Apache. You can find a simple ‘Hello World’ WSGI application, along with setup instructions for the traditional way of setting up Apache and mod_wsgi, described in the Quick Configuration Guide. For a bit more in-depth information and additional examples see the Configuration Guidelines. Note that unless you are using Windows, where such a choice is not available, you should always use daemon mode of mod_wsgi. This is not the default mode, so you will need to ensure you follow the instructions to enable daemon mode. For a simpler way of running a Python WSGI application using mod_wsgi, also checkout mod_wsgi-express, details of which can currently be found at: https://pypi.python.org/pypi/mod_wsgi 7 mod_wsgi Documentation, Release 4.9.0 8 Chapter 3. Getting Started CHAPTER 4 Requirements The mod_wsgi package can be compiled for and used with most recent patch revisions of Apache 2.0, 2.2 or 2.4 on UNIX like systems, such as Linux and MacOS X, as well as Windows. It is highly recommended that you use Apache 2.4. Older versions of Apache have architectural design problems and sub optimal configuration defaults, that can result in excessive memory usage in certain circumstances. More recent mod_wsgi versions attempt to protect against these problems in Apache 2.0 and 2.2, however it is still better to use Apache 2.4. Any of the single threaded ‘prefork’ or multithreaded ‘worker’ and ‘event’ Apache MPMs can be used when running on UNIX like systems. Both Python 2 and 3 are supported. The minimum recommended versions of each being Python 2.6 and 3.3 respec- tively. The Python installation must have been installed in a way that shared libraries for Python are provided such that embedding of Python in another application is possible. The mod_wsgi package should be able to host any Python web application which complies with the WSGI specifi- cation (PEP 3333). The implementation is very strict with its interpretation of the WSGI specification. Other WSGI servers available aren’t as strict and allow Python web applications to run which do not comply with the WSGI speci- fication. If your Python web application doesn’t comply properly with the WSGI specification, then it may fail to run or may run sub optimally when using mod_wsgi. 9 mod_wsgi Documentation, Release 4.9.0 10 Chapter 4. Requirements CHAPTER 5 Installation The mod_wsgi package can be installed from source code or may also be available as a pre built binary package as part of your Linux distribution. Do be aware though that Linux distributions generally ship out of date versions of mod_wsgi and for long term support (LTS) versions of Linux can be anything up to about 5 years old. Those older versions are not supported in any way even though they are part of a so called LTS version of Linux. If you want support and want to ensure you have the most up to date and bug free version of mod_wsgi, you should consider building and installing mod_wsgi from the source code. For instructions on how to compile mod_wsgi from the source code for UNIX like operating systems such as Linux and MacOS X see: • Quick Installation Guide • Installation On MacOS X If you are on Windows, you should instead use: • https://github.com/GrahamDumpleton/mod_wsgi/blob/develop/win32/README.rst 11 mod_wsgi Documentation, Release 4.9.0 12 Chapter 5. Installation CHAPTER 6 Troubleshooting If you are having problems getting mod_wsgi to start up or do what you want it to do, first off ensure that you read the following documents: • Installation Issues • Configuration Issues • Application Issues You can also do some basic checking of your installation and configuration to validate that how it is setup is how you expect it to be. See the following document: • Checking Your Installation If none of the common issues match up with the problem you are seeing and are after other ideas, or you have the need to perform more low level debugging, check out the User Guides. 13 mod_wsgi Documentation, Release 4.9.0 14 Chapter 6. Troubleshooting CHAPTER 7 User Guides 7.1 Quick Installation Guide This document describes the steps for installing mod_wsgi on a UNIX system from the original source code. 7.1.1 Apache Requirements Apache 2.0, 2.2 or 2.4 can be used. For Apache 2.0, 2.2 and 2.4, the single threaded ‘prefork’ or multithreaded ‘worker’ Apache MPMs can be used. For Apache 2.4 the ‘event’ MPM can also be used. The version of Apache and its runtime libraries must have be compiled with support for threading. On Linux systems, if Apache has been installed from a package repository, you must have installed the corresponding Apache “dev” package as well. For most Linux distributions, the “dev” package for Apache 2.X is “apache2-dev” where the corresponding Apache package was “apache2”. Some systems however distinguish the “dev” package based on which MPM is used by Apache. As such, it may also be called “apache2-worker-dev” or “apache2-prefork-dev”. If using Apache 2.X, do not mix things up and install “apache-dev” by mistake, which is the “dev” package for Apache 1.3 called just “apache”. 7.1.2 Python Requirements Any Python 2.X version from Python 2.6 onwards can be used. For Python 3.X, you will need Python 3.3 or later. The version of Python being used must have been compiled with support for threading. On Linux systems, if Python has been installed from a package repository, you must have installed the corresponding Python “dev” package as well. Python should preferably be available as a shared library. If this is not the case then base runtime memory usage of mod_wsgi will be greater. 15 mod_wsgi Documentation, Release 4.9.0 7.1.3 Unpacking The Source Code Source code tar balls can be obtained from: • https://github.com/GrahamDumpleton/mod_wsgi/releases After having downloaded the tar ball for the version you want to use, unpack it with the command: tar xvfz mod_wsgi-X.Y.tar.gz Replace ‘X.Y’ with the actual version number for that being used.
Load more

Recommended publications
  • Systems Programming II
    Systems Programming II Iqbal Mohomed CSC 209 – Summer 2004 Week 7 Motivation for Signals • When a program forks into 2 or more processes, rarely do they execute independently of each other • The processes usually require some form of synchronization, and this is typically handled using signals. Job control is another important use • Data usually needs to be passed between processes also, and this is typically handled using pipes and sockets, which we will discuss shortly • Signals are usually generated by – Machine interrupts – The program itself, other programs, or the user (i.e. from the keyboard) Introduction to Signals • When a C program receives a signal, control is immediately passed to a function called a signal handler • The signal handler function can execute some C statements and exit in three different ways: – Return control to the place in the program which was executing when the signal occurred – Return control to some other point in the program – Terminate the program by calling the exit (or _exit) function signal() • A default action is provided for each kind of signal, such as terminate, stop or ignore • For nearly all signal types, the default action can be changed using the signal() function. The exceptions are SIGKILL and SIGSTOP. The handler is defined as follows: – typedef void (*sighandler_t)(int); • To change the handler: – sighandler_t signal(int signum, sighandler_t handler); More on signal() • For each process, the OS maintains a table of actions that should be performed for each kind of signal. The signal() function changes the table entry for the signal named as the first argument to the value provided as the second argument.
    [Show full text]
  • Building a Scalable Index and a Web Search Engine for Music on the Internet Using Open Source Software
    Department of Information Science and Technology Building a Scalable Index and a Web Search Engine for Music on the Internet using Open Source software André Parreira Ricardo Thesis submitted in partial fulfillment of the requirements for the degree of Master in Computer Science and Business Management Advisor: Professor Carlos Serrão, Assistant Professor, ISCTE-IUL September, 2010 Acknowledgments I should say that I feel grateful for doing a thesis linked to music, an art which I love and esteem so much. Therefore, I would like to take a moment to thank all the persons who made my accomplishment possible and hence this is also part of their deed too. To my family, first for having instigated in me the curiosity to read, to know, to think and go further. And secondly for allowing me to continue my studies, providing the environment and the financial means to make it possible. To my classmate André Guerreiro, I would like to thank the invaluable brainstorming, the patience and the help through our college years. To my friend Isabel Silva, who gave me a precious help in the final revision of this document. Everyone in ADETTI-IUL for the time and the attention they gave me. Especially the people over Caixa Mágica, because I truly value the expertise transmitted, which was useful to my thesis and I am sure will also help me during my professional course. To my teacher and MSc. advisor, Professor Carlos Serrão, for embracing my will to master in this area and for being always available to help me when I needed some advice.
    [Show full text]
  • Unix System Programming Overview Outline What Is a Signal? Signal
    Overview Last Week: ● How to program UNIX processes (Chapters 7-9) ● fork() and exec() Unix System Programming This Week, and next week: ● UNIX inter-process communication mechanisms: signals, Signals » (next week) pipes and FIFOs. ● How to program with UNIX signals (Chapter 10) » http://en.wikipedia.org/wiki/Unix_signal ● Non-local jumps (Chapter 7) ● Focus on the sigaction() function Maria Hybinette, UGA 1 Maria Hybinette, UGA 2 Outline What is a Signal? ● A signal is an asynchronous event which is ● What is a UNIX signal? delivered to a process (instantiated by a small message) ● Signal types ● Asynchronous means that the event can occur ● Generating signals at any time (e.g., posting at a bulletin board ) ● Responding to a signal » may be unrelated to the execution of the process ● Common uses of a signal – e.g., user types Ctrl-C, or the modem hangs (SIGINT) ● Implementing a read() time-out – e.g,, user types Ctrl-Z (SIGTSTP) ● Sent from kernel (e.g. detects divide by zero ● Non-local jumps setjmp()/longjmp() (SIGFPE) or could be at the request of another ● POSIX signals process to send to another) ● Interrupted system calls ● Only information that a signal carries is its ● System calls inside handlers unique ID and that it arrived Maria Hybinette, UGA 3 Maria Hybinette, UGA 4 Signal Types (31 in POSIX) Signal Sources terminal memory ID Name Description Default Action driver management shell command 2 SIGINT Interrupt from keyboard (^C) terminate Ctr-C SIGINT SIGHUP 3 SIGQUIT Quit from keyboard (^\) terminate & core SIGSEGV 9 SIGKILL
    [Show full text]
  • POSIX Signals
    CSE 410: Systems Programming POSIX Signals Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Signals Blocking Concurrency Sending Signals Summary References POSIX Signals POSIX signals are another form of interprocess communication. They are also a way to create concurrency in programs. For these two reasons, they are rather complicated and subtle! Signals provide a simple message passing mechanism. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals as Messages POSIX signals are asynchronous messages. Asynchronous means that their reception can occur at any time.1 The message is the reception of the signal itself. Each signal has a number, which is a small integer. POSIX signals carry no other data. 1Almost. We’ll see how to control it later. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signal Types There are two basic types of POSIX signals: Reliable signals Real-time signals Real-time signals are much more complicated. In particular, they can carry data. We will discuss only reliable signals in this lecture. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Asynchronous Reception From the point of view of the application: Signals can be blocked or ignored Enabled signals may be received between any two processor instructions A received signal can run a user-defined function called a signal handler This means that enabled signals and program code must very carefully manipulate shared or global data! © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals POSIX defines a number of signals by name and number.
    [Show full text]
  • Programming with POSIX Threads II
    Programming with POSIX Threads II CS 167 IV–1 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Global Variables int IOfunc( ) { extern int errno; ... if (write(fd, buffer, size) == –1) { if (errno == EIO) fprintf(stderr, "IO problems ...\n"); ... return(0); } ... } CS 167 IV–2 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Unix was not designed with multithreaded programming in mind. A good example of the implications of this is the manner in which error codes for failed system calls are made available to a program: if a system call fails, it returns –1 and the error code is stored in the global variable errno. Though this is not all that bad for single-threaded programs, it is plain wrong for multithreaded programs. Coping • Fix Unix’s C/system-call interface • Make errno refer to a different location in each thread – e.g. #define errno __errno(thread_ID) CS 167 IV–3 Copyright © 2008 Thomas W. Doeppner. All rights reserved. The ideal way to solve the “errno problem” would be to redesign the C/system-call interface: system calls should return only an error code. Anything else to be returned should be returned via result parameters. (This is how things are done in Windows NT.) Unfortunately, this is not possible (it would break pretty much every Unix program in existence). So we are stuck with errno. What can we do to make errno coexist with multithreaded programming? What would help would be to arrange, somehow, that each thread has its own private copy of errno. I.e., whenever a thread refers to errno, it refers to a different location from any other thread when it refers to errno.
    [Show full text]
  • POSIX Signal Handling in Java
    Technical Document Series POSIX Signal Handling in Java POSIX Signal Handling In Java Introduction POSIX signals inform a running process of external events, such as the user wishing to kill the process, or the operating system signaling an impending shutdown, or the process being suspended or reinstated; or the process may have violated a resource constraint, such as excessive CPU usage or attempts to access areas outside its permitted memory space, and is asked to shutdown. In short, POSIX signals serve many different purposes. Some are even up to interpretation, such as the HUP (HangUP) signal, which is commonly used to inform a process that something about its environment has changed and the process should adjust accordingly. Some programs may interpret this to mean that the configuration has changed and needs to be reloaded; or the log file has been moved for archiving purposes and a new one should be started. The use of signals is widespread, especially on Unix-based operating systems, but Java provides no standard interface for a Java application to hear and react to them. This document shows you how to get around this limitation. The Good, the Bad, and the Ugly The good news is that there is a way to intercept POSIX signals and react to them in Java. This would allow your Java program to avoid being killable with ^C (SIGINT), for example, even ignore termination requests from the operating system (SIGTERM). Neither of these is necessarily a good idea, of course, unless you know exactly why you would want to catch these signals and either handle them yourself or ignore them altogether.
    [Show full text]
  • Processes and Job Control
    Processes and Job Control Hour 17 PObjectives < Definitions: process, orphan, and zombie < System processes < Process creation < Examining processes: the ps command < Job control: &, nohup, fg, bg, jobs, ( ), and kill < Exit status Copyright © 1998-2002 Delroy A. Brinkerhoff. All Rights Reserved. Hour 17 Unix Slide 1 of 12 Process Also called a job by C and Korn shells PWhen a program or executable file is loaded from disk and started running (i.e., when a command is run), it is called a process vi pid 641 < identified by a unique process ID (PID) number < has an owner vi < private data vi PA program can be loaded more than once pid 895 < creates multiple processes vi < each process has a different PID < each process may have a different owner PPIDs are unique, nonnegative integers < numbers recycle without collisions Hour 17 Unix Slide 2 of 12 System Processes Processes created during system boot P0System kernel < “hand crafted” at boot < called swap in older versions (swaps the CPU between processes) < called sched in newer versions (schedules processes) < creates process 1 P1 init (the parent of all processes except process 0) < general process spawner < begins building locale-related environment < sets or changes the system run-level P2 page daemon (pageout on most systems) P3 file system flusher (fsflush) Hour 17 Unix Slide 3 of 12 Process Life Cycle Overview of creating new processes fork init init pid 467 Pfork creates two identical pid 1 exec processes (parent and child) getty pid 467 Pexec < replaces the process’s instructions
    [Show full text]
  • Site Map - Apache HTTP Server 2.0
    Site Map - Apache HTTP Server 2.0 Apache HTTP Server Version 2.0 Site Map ● Apache HTTP Server Version 2.0 Documentation ❍ Release Notes ■ Upgrading to 2.0 from 1.3 ■ New features with Apache 2.0 ❍ Using the Apache HTTP Server ■ Compiling and Installing Apache ■ Starting Apache ■ Stopping and Restarting the Server ■ Configuration Files ■ How Directory, Location and Files sections work ■ Server-Wide Configuration ■ Log Files ■ Mapping URLs to Filesystem Locations ■ Security Tips ■ Dynamic Shared Object (DSO) support ■ Content Negotiation ■ Custom error responses ■ Setting which addresses and ports Apache uses ■ Multi-Processing Modules (MPMs) ■ Environment Variables in Apache ■ Apache's Handler Use ■ Filters ■ suEXEC Support ■ Performance Hintes ■ URL Rewriting Guide ❍ Apache Virtual Host documentation ■ Name-based Virtual Hosts ■ IP-based Virtual Host Support ■ Dynamically configured mass virtual hosting ■ VirtualHost Examples ■ An In-Depth Discussion of Virtual Host Matching ■ File descriptor limitations ■ Issues Regarding DNS and Apache ❍ Apache Server Frequently Asked Questions http://httpd.apache.org/docs-2.0/sitemap.html (1 of 4) [5/03/2002 9:53:06 PM] Site Map - Apache HTTP Server 2.0 ■ Support ❍ Apache SSL/TLS Encryption ■ SSL/TLS Encryption: An Introduction ■ SSL/TLS Encryption: Compatibility ■ SSL/TLS Encryption: How-To ■ SSL/TLS Encryption: FAQ ■ SSL/TLS Encryption: Glossary ❍ Guides, Tutorials, and HowTos ■ Authentication ■ Apache Tutorial: Dynamic Content with CGI ■ Apache Tutorial: Introduction to Server Side Includes ■ Apache
    [Show full text]
  • Improved Methods for Mining Software Repositories to Detect Evolutionary Couplings
    IMPROVED METHODS FOR MINING SOFTWARE REPOSITORIES TO DETECT EVOLUTIONARY COUPLINGS A dissertation submitted to Kent State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy by Abdulkareem Alali August, 2014 Dissertation written by Abdulkareem Alali B.S., Yarmouk University, USA, 2002 M.S., Kent State University, USA, 2008 Ph.D., Kent State University, USA, 2014 Approved by Dr. Jonathan I. Maletic Chair, Doctoral Dissertation Committee Dr. Feodor F. Dragan Members, Doctoral Dissertation Committee Dr. Hassan Peyravi Dr. Michael L. Collard Dr. Joseph Ortiz Dr. Declan Keane Accepted by Dr. Javed Khan Chair, Department of Computer Science Dr. James Blank Dean, College of Arts and Sciences ii TABLE OF CONTENTS TABLE OF CONTENTS ............................................................................................... III LIST OF FIGURES ..................................................................................................... VIII LIST OF TABLES ....................................................................................................... XIII ACKNOWLEDGEMENTS ..........................................................................................XX CHAPTER 1 INTRODUCTION ................................................................................... 22 1.1 Motivation and Problem .......................................................................................... 24 1.2 Research Overview ................................................................................................
    [Show full text]
  • NYC*BUG in Perspective
    Tens Years of NYC*BUG in Perspective versioning ● 10 years is actually December/January ● aimed at a broader audience than just people here ● start an UG? ● “organizational” angle THIS IS A DOT RELEASE my perspective ● I'm not the only one ● many other significant players ● my role exaggerated ● the “philosophical” one ● difficult talk: 10 years I posit that ● We're not the best thing since sliced bread ● We're just a user group But... ● Much significant impact, in NYC and beyond ● The community is better to have us ● Would be better if there were more like us I posit that ● We're not the best thing since sliced bread ● We're just a user group But... ● Much significant impact, in NYC and beyond ● The community is better to have us ● Would be better if there were more like us What Was Clear ● No to “Hobbyism” ● No to “Professionalism” ● No to “Sales” (Apple 2004 meeting) ● Neither a software project nor technical meritocracy ● Free, open, loose ● Needed LOTS of planning (mailing list stats) ● Viewed ourselves as part of a wider community, whether they liked it or not ● People + Technology = success For instance... http://mail-index.netbsd.org/regional-nyc/2004/01/13/0003.html Subject: Re: NYCBUG To: None <[email protected]> From: Michael Shalayeff <[email protected]> List: regional-nyc Date: 01/13/2004 12:51:01 Making, drinking tea and reading an opus magnum from Andrew Brown: > > http://lists.freebsd.org/pipermail/freebsd-advocacy/2004- January/000873.html > > i wonder if beer is involved...there's no mention of it in that posting.
    [Show full text]
  • System Calls & Signals
    CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..
    [Show full text]
  • The GNU General Public License (GPL) Does Govern All Other Use of the Material That Constitutes the Autoconf Macro
    Notice About this document The following copyright statements and licenses apply to software components that are distributed with various versions of the StorageGRID PreGRID Environment products. Your product does not necessarily use all the software components referred to below. Where required, source code is published at the following location: ftp://ftp.netapp.com/frm-ntap/opensource/ 215-10078_A0_ur001-Copyright 2015 NetApp, Inc. All rights reserved. 1 Notice Copyrights and licenses The following component is subject to the BSD 1.0 • Free BSD - 44_lite BSD 1.0 Copyright (c) 1982, 1986, 1990, 1991, 1993 The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. • All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. • Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
    [Show full text]