{
    "info": {
        "author": "Emmanuel Blot",
        "author_email": "emmanuel.blot@free.fr",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 4 - Beta",
            "Environment :: No Input/Output (Daemon)",
            "Intended Audience :: Developers",
            "Intended Audience :: System Administrators",
            "License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL)",
            "Operating System :: MacOS :: MacOS X",
            "Operating System :: POSIX",
            "Programming Language :: Python :: 2.6",
            "Programming Language :: Python :: 2.7",
            "Topic :: Internet",
            "Topic :: System :: Installation/Setup",
            "Topic :: System :: Networking",
            "Topic :: Utilities"
        ],
        "description": "+++++++\nPyBootd\n+++++++\n\nOverview\n~~~~~~~~\n\nPyBootd is a daemon supporting a subset of the BOOTP, DHCP, PXE and TFTP\nprotocols, with some handy extensions.\n\nOne of its main goals is to provide a simple solution to boot up any\nPXE-enabled personal computer, with no other tool required but a standard\nPython installation.\n\nPybootd can be used for any network boot up, or to install an OS without any\nphysical support such as a USB key or a CD/DVD.\n\nRequirements\n~~~~~~~~~~~~\n\nPython\n------\n\n- Python_ 2.6 or above is required. Python_ 3.x is not yet supported.\n- Netifaces_ Python module\n\n.. _Python: http://python.org/\n.. _Netifaces: http://alastairs-place.net/netifaces/\n\nPermissions\n-----------\n\n- DHCP protocol requires the daemon to listen on port 67.\n- TFTP protocol requires the daemon to listen on port 69.\n\nAs these ports are within the server's range (<1024), the superuser privileges\nare required on Unix hosts (Linux, Mac OS X, ...) to start up these daemons.\n\nStatus\n~~~~~~\n\nThis project is in beta development stage.\n\nSupported features\n~~~~~~~~~~~~~~~~~~\n- Access control:\n\n 1. None (any remote host can be served)\n 2. MAC address ACL\n 3. UUID based ACL - requires PXE protocol\n 4. HTTP forwarding - authorization is delegated to a remote server using\n    simple HTTP GET requests\n\n- Local or remote file serving:\n\n - For example, it is possible to boot up a full Debian system directly from\n   the Internet, without storing any file on the pybootd host machine\n\n- Network notification of client requests through UDP messages\n\n- File name translation\n\n  - Files requested from TFTP clients can be filtered and transformed into\n    local filenames using filters\n\n- It is possible to use pybootd with only one of the services, either TFTP or\n  DHCP\n\nFAQ\n~~~\n\nCommon errors\n-------------\n\n``pybootd.pxed.BootpError: Unable to detect network configuration``\n  This error is often triggered when the ``pool_start`` address is not part of\n  a valid network. Double check the network configuration and fix up the\n  ``[bootp]`` section so that it matches the actual network.\n\nConfiguration\n-------------\n\n``pybootd`` has a few option switches. The server offers two services: bootp\n(which supports Dhcp and PXE extensions) and tftp. It is possible to disable\neither services.\n\nUsage: pybootd.py [options]\n   PXE boot up server, a tiny BOOTP/DHCP/TFTP server\n\nOptions:\n  -h, --help            show this help message and exit\n  -c CONFIG, --config=CONFIG\n                        configuration file\n  -p, --pxe             enable BOOTP/DHCP/PXE server only\n  -t, --tftp            enable TFTP server only\n\n``pybootd`` daemon uses a configuration file, in ``.ini`` format, for all other\noptions.\n\nSome options accept a boolean value. The following values are recognized:\n\n- true values: ``on``, ``true``, ``enable``, ``enabled``, ``yes``, ``high``,\n  ``ok``, ``1``\n- false values: ``off``, ``false``, ``disable``, ``disabled``, ``no``, ``low``,\n  ``ko``, ``0``\n\nThe BOOTP daemon associates each MAC address to an assigned IP address. As long\nas the BOOTP daemon is running, the same IP address is always assigned to the\nsame client. The address never gets back to the pool, *i.e.* it cannot be\nre-assigned to another machine even when the lease expires.\n\nThis is especially useful for a full network-based installation, where each\nclient requests at least an IP address twice:\n\n- when BIOS kicks off, its PXE ROM code requests an IP address, then requests\n  an executable to run,\n- when the executable runs, it usually boots up an OS (Linux, ...), which in\n  turn requests an IP address to resume the installation.\n\n``[logger]`` section\n....................\n\n``type``\n   The type of logger, if any. ``stderr``, ``file``, ``syslog`` or ``none``.\n\n``level``\n   The level of logger verbosity. ``critical``, ``error``, ``info`` or\n   ``debug``.\n\n``file``\n   The path to the output log file, if ``type`` is set to ``file``.\n\n``[bootp]`` section\n...................\n\n``access``\n   Type of access control list. If this option is not defined, all BOOTP\n   requests are served, as long as the defined pool is not exhausted. It can be\n   one among the following options:\n\n   - ``mac``: incoming BOOTP requests are filtered out based on the MAC address\n     of the requester.\n   - ``uuid``: incoming PXE requests are filtered out based on the UUID of the\n     request. UUIDs are not emitted from simple BOOTP or DHCP clients, so this\n     option is only meaningful for PXE-enabled clients.\n   - ``http``: incoming requests are forwarded to another host, through simple\n     HTTP GET requests. The MAC address and the UUID if it exists, are sent\n     to the HTTP server which replies to grant or deny access to the requester.\n\n   A section named after the selected option should exist to define the access\n   list.\n\n``address``\n   Specifies the network to listen to requesters for receiving incoming BOOTP\n   requests. On most hosts, the only valid address is ``0.0.0.0``. Some hosts\n   accept subnetworks (such as ``192.168.1.0``). It is recommended not to\n   define this option, and use an ACL to reject clients. Hosts will multiple\n   network interfaces, it might not be possible to listen to single network.\n   Implementing such as feature would require to use RAW sockets, which falls\n   out of scope for this simple server.\n\n``allow_simple_dhcp``\n   The default behaviour is to expect PXE requests. In order to serve simple\n   BOOTP or DHCP requests, this option should be enabled. This option accepts\n   a boolean value.\n\n``boot_file``\n   Boot filename to send back to the BOOTP client, which usually requests such\n   a file over TFTP to boot up after it has been assigned a network address.\n\n``domain``\n   Domain part of the client FQDN, that is the network's domain name.\n\n``dns``\n   IP address of the DNS server. The server only accepts a single address.\n\n``lease_time``\n   Validity in seconds of a DHCP lease. Please note that the BOOTP daemon does\n   not manage lease expiration; this value has therefore little meaning.\n\n``pool_start``\n   First address to allocate for a BOOT client.\n\n``pool_count``\n   The maximum number of clients that can be served.\n\n``notify``\n   When defined, the IP address and port (using a column separator:\n   ``a.b.c.d:p``) to which a UDP notification message should be sent whenever\n   a client requests an IP address to the BOOTP daemon.\n\n``port``\n   Alternative port for incoming BOOTP requests.\n\n``timeout``\n   Timeout in seconds for a response from a remote authentication host to be\n   received, when ACL is enabled and set to use the HTTP protocol. If no answer\n   is received from the remote host, the BOOTP daemon ignores the incoming\n   BOOTP/DHCP request.\n\n``servername``\n   Name of the BOOTP server.\n\n``[mac]`` section\n.................\n\n   The ``[mac]`` section contains one entry for each MAC address to allow or\n   block. The value for each entry is a boolean, *i.e.*::\n\n     AA-BB-CC-DD-EE-FF = enable\n\n\n``[uuid]`` section\n..................\n\n   The ``[uuid]`` section contains one entry for each UUID to allow or block.\n   The value for each entry is a boolean, *i.e.*::\n\n     xxxxxxxx-aaaa-bbbb-cccc-yyyyyyyyyyyy = enable\n\n``[http]`` section\n..................\n\n``location``\n   The URL prefix to contact the remote server for boot permission.\n\n``pxe``\n   The path to append to the URL prefix when the requester emits PXE\n   information. A regular PC with PXE capability emits a PXE boot request when\n   the BIOS kicks off. The remote HTTP server may therefore identify a BIOS\n   boot sequence upon receiving this kind of request from the *pybootd* daemon.\n\n``dhcp``\n   The path to append to the URL prefix when the requester emits simple DHCP\n   information. A regular OS emits a simple DHCP request at start up. The\n   remote HTTP server may therefore identify an OS boot sequence upon receiving\n   this kind of request from the *pybootd* daemon.\n\nThe ``pxe``/``dhcp`` option pair enables the remote HTTP server to identify\nthe boot phase: either a BIOS initialization or an OS boot sequence. When such\ndifferentiation is useless, both options may refer to the same path.\n\n``[tftp]`` section\n..................\n\n``address``\n   Address to listen to incoming TFTP requests. When the BOOTP daemon is\n   enabled this option is better omitted, as the address is automatically\n   received from the BOOTP daemon.\n\n``blocksize``\n   Size of each exchanged data block. It is recommended to leave the default\n   value, as some clients may not accept other values.\n\n``port``\n   Alternative port for incoming TFTP request.\n\n``timeout``\n   Timeout in seconds for an acknowledgment from the TFTP client to be\n   received. If the timeout expires the TFTP server retransmits the last\n   packet. It can be expressed as a real value.\n\n``root``\n   Base directory for the TFTP service. This path is automatically prepended\n   to the pathname issued from the TFTP client. It can either be:\n\n   - a relative path to the daemon directory, when the ``root`` option starts\n     with ``./``,\n   - an absolute path, when the ``root`` option starts with ``/``,\n   - a URL prefix, to access remote files.\n\n``[filters]`` section\n.....................\n\nThe ``filters`` section allows on-the-fly pathnames transformation. When a TFTP\nclient requests some specific filenames, the *tftp* server can translate them\nto other ones.\n\nThis option is useful to serve the very same configuration file (''e.g.''\n``pxelinux.cfg``) whatever the remote client, thus speeding up the boot\nprocess. This option also enables to access files that are not stored within\nthe currently configured path (see the ``root`` option).\n\nEach option of the ``filters`` section represents a file pattern to match. It\naccepts standard wildcard characters: `*` and `?`. The option's value defines\nthe translated path.\n\nThe *value* part can contain variables. Variables are written with enclosing\nbraces, such as ``{varname}``.\n\nFor now, the only supported variable is ``filename``, which is replaced with\nthe actual requested filename.\n\nThe *value* part can also contain a special marker, that tells the *tftp*\ndaemon to read the replacement pattern from a file. This special marker should\nbe written with enclosing brackets, such as ``[file]``.\n\nExamples\n........\n\nThe following filter::\n\n  pxelinux.cfg/* = pybootd/etc/pxe.cfg\n\ntells the *tftp* server that all client requests matching the\n``pxelinux.cfg/*`` pattern should be served the ``pybootd/etc/pxe.cfg`` file\ninstead. This prevents the client to perform the usual time-costing fallback\nrequests using UUID, MAC, and suffix addresses before eventually falling\nback to the simple ``pxelinux.cfg`` file.\n\nThe following filter::\n\n  startup = [dir/{filename}.cfg]\n\ntells the *tftp* server that when the ``startup`` file is requested, it should\nread out the actual filename from the ``dir/startup.cfg`` file.\n\nHTTP-based authentication\n-------------------------\n\nThis option enabled the delegation of the BOOTP authorization to a remote web\nserver. As *pybootd* emits standard HTTP GET requests and expects standard\nHTTP reply codes, any web server may be used to manage authorizations.\n\nThis web server receives HTTP GET requests with URLs formatted as follows::\n\n  http://server/path?mac=AA-BB-CC-DD-EE-FF&uuid=xxxxxxxx-aaaa-bbbb-cccc-yyyyyyyyyyyy\n\nwhere:\n\n- ``http://server`` matches the ``location`` option,\n- ``/path`` matches the ``pxe`` or ``dhcp`` options of the ``[http]`` section.\n\nThe web server should reply either with:\n\n- ``200 Ok`` result if the requester is to be assigned an IP address, or\n- ``401 Unauthorized`` result if it is to be ignored.\n\nThe ``pybootd`` package contains a minimalist HTTP server that demonstrates\nthis feature. It can be found within the ``tests/`` subdirectory. See the\n``config.ini`` file for this test daemon. The test daemon expects the ``pxe``\npath to be set to ``/boot`` and the ``dhcp`` path to ``/linux``.\n\nSample configurations\n~~~~~~~~~~~~~~~~~~~~~\n\nInstalling a Debian 6.0 machine from the official archive\n---------------------------------------------------------\nAs the *tftp* daemon is able to retrieve remote files using the HTTP protocol,\nthere is no need to manually download any file from a Debian mirror. The daemon\nwill forward all file requests to the mirror on behalf of the client being\ninstalled.\n\nThe ``pybootd.ini`` would contain::\n\n  [logger]\n  ; show requests on the standard error output of the daemon\n  type = stderr\n  ; show informative and error messages only (disable verbose mode)\n  level = info\n\n  [bootp]\n  ; do not force a full PXE boot-up cycle to accept the client\n  allow_simple_dhcp = enable\n  ; First BOOTP/DHCP address to generate\n  pool_start = 192.168.1.100\n  ; Google DNS\n  dns = 8.8.8.8\n  ; boot-up executable the client should request through TFTP\n  boot_file = pxelinux.0\n\n  [tftp]\n  ; URL to install a Debian 6.0 Intel/AMD 64-bit network installation\n  root = http://http.us.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot\n\n  [filters]\n  ; serve a simple configuration file to the linux PXE helper\n  pxelinux.cfg/* = pybootd/etc/pxe.cfg\n\nThe ``pool_start`` parameter should be a valid address on the host's networks,\nand the ``root`` URL may be changed to use alternative mirror and path.\n\nPlease note that to complete the network installation, the client should be\nable to access the remote resources on its own - as with a network ISO image\ninstallation. There are two ways to achieve this:\n\n- either enable IP forwarding on the *pybootd* host (see ``forward.sh``\n  script within the ``pybootd`` package), or\n- be sure to connect the network cable of the client to a LAN that has direct\n  access to the Internet, once the first installation stage is complete.",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "https://github.com/eblot/pybootd/tarball/master",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://github.com/eblot/pybootd",
        "keywords": "bootp ftdp dhcp pxe netboot",
        "license": "LGPL v2",
        "maintainer": null,
        "maintainer_email": null,
        "name": "pybootd",
        "package_url": "https://pypi.org/project/pybootd/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/pybootd/",
        "project_urls": {
            "Download": "https://github.com/eblot/pybootd/tarball/master",
            "Homepage": "http://github.com/eblot/pybootd"
        },
        "release_url": "https://pypi.org/project/pybootd/1.5.0/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "Simplified BOOTP/DHCP/PXE/TFTP server",
        "version": "1.5.0"
    },
    "last_serial": 329163,
    "releases": {
        "1.5.0": []
    },
    "urls": []
}