DOCSLIB.ORG

Uwsgi Documentation Release 2.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Uwsgi Documentation Release 2.0 uWSGI Documentation Release 2.0 uWSGI Jun 17, 2020 Contents 1 Included components (updated to latest stable release)3 2 Quickstarts 5 3 Table of Contents 33 4 Tutorials 303 5 Articles 343 6 uWSGI Subsystems 375 7 Scaling with uWSGI 457 8 Securing uWSGI 485 9 Keeping an eye on your apps 503 10 Async and loop engines 511 11 Web Server support 525 12 Language support 541 13 Other plugins 629 14 Broken/deprecated features 633 15 Release Notes 643 16 Contact 741 17 Commercial support 743 18 Donate 745 19 Sponsors 747 20 Indices and tables 749 i Python Module Index 751 Index 753 ii uWSGI Documentation, Release 2.0 The uWSGI project aims at developing a full stack for building hosting services. Application servers (for various programming languages and protocols), proxies, process managers and monitors are all implemented using a common api and a common configuration style. Thanks to its pluggable architecture it can be extended to support more platforms and languages. Currently, you can write plugins in C, C++ and Objective-C. The “WSGI” part in the name is a tribute to the namesake Python standard, as it has been the first developed plugin for the project. Versatility, performance, low-resource usage and reliability are the strengths of the project (and the only rules fol- lowed). Contents 1 uWSGI Documentation, Release 2.0 2 Contents CHAPTER 1 Included components (updated to latest stable release) The Core (implements configuration, processes management, sockets creation, monitoring, logging, shared memory areas, ipc, cluster membership and the uWSGI Subscription Server) Request plugins (implement application server interfaces for various languages and platforms: WSGI, PSGI, Rack, Lua WSAPI, CGI, PHP, Go . ) Gateways (implement load balancers, proxies and routers) The Emperor (implements massive instances management and monitoring) Loop engines (implement events and concurrency, components can be run in preforking, threaded, asyn- chronous/evented and green thread/coroutine modes. Various technologies are supported, including uGreen, Greenlet, Stackless, Gevent, Coro::AnyEvent, Tornado, Goroutines and Fibers) Note: uWSGI is a very active project with a fast release cycle. For this reason the code and the documentation may not always be in sync. We try our best to have good documentation, but it is a hard work. Sorry for that. If you are in trouble, the mailing list is the best source for help regarding uWSGI. Contributors for documentation (in addition to code) are always welcome. 3 uWSGI Documentation, Release 2.0 4 Chapter 1. Included components (updated to latest stable release) CHAPTER 2 Quickstarts 2.1 Quickstart for Python/WSGI applications This quickstart will show you how to deploy simple WSGI applications and common web frameworks. Python here is meant as CPython, for PyPy you need to use the specific plugin: The PyPy plugin, Jython support is under construction. Note: You need at least uWSGI 1.4 to follow the quickstart. Anything older is no longer maintained and is highly buggy! 2.1.1 Installing uWSGI with Python support Tip: When you start learning uWSGI, try to build from official sources: using distribution-supplied packages may bring you plenty of headaches. When things are clear, you can use modular builds (like the ones available in your distribution). uWSGI is a (big) C application, so you need a C compiler (like gcc or clang) and the Python development headers. On a Debian-based distro an apt-get install build-essential python-dev will be enough. You have various ways to install uWSGI for Python: • via pip pip install uwsgi 5 uWSGI Documentation, Release 2.0 • using the network installer curl http://uwsgi.it/install | bash -s default /tmp/uwsgi (this will install the uWSGI binary into /tmp/uwsgi, feel free to change it). • via downloading a source tarball and “making” it wget https://projects.unbit.it/downloads/uwsgi-latest.tar.gz tar zxvf uwsgi-latest.tar.gz cd <dir> make (after the build you will have a uwsgi binary in the current directory). Installing via your package distribution is not covered (would be impossible to make everyone happy), but all of the general rules apply. One thing you may want to take into account when testing this quickstart with distro-supplied packages, is that very probably your distribution has built uWSGI in modular way (every feature is a different plugin that must be loaded). To complete this quickstart, you have to prepend --plugin python,http to the first series of examples, and --plugin python when the HTTP router is removed (if this doesn’t make sense to you, just continue reading). 2.1.2 The first WSGI application Let’s start with a simple “Hello World” example: def application(env, start_response): start_response('200 OK', [('Content-Type','text/html')]) return [b"Hello World"] (save it as foobar.py). As you can see, it is composed of a single Python function. It is called “application” as this is the default function that the uWSGI Python loader will search for (but you can obviously customize it). 2.1.3 Deploy it on HTTP port 9090 Now start uWSGI to run an HTTP server/router passing requests to your WSGI application: uwsgi --http :9090 --wsgi-file foobar.py That’s all. Note: Do not use --http when you have a frontend webserver or you are doing some form of benchmark, use --http-socket. Continue reading the quickstart to understand why. 2.1.4 Adding concurrency and monitoring The first tuning you would like to make is adding concurrency (by default uWSGI starts with a single process and a single thread). You can add more processes with the --processes option or more threads with the --threads option (or you can have both). 6 Chapter 2. Quickstarts uWSGI Documentation, Release 2.0 uwsgi --http :9090 --wsgi-file foobar.py --master --processes4 --threads2 This will spawn 4 processes (each with 2 threads), a master process (will respawn your processes when they die) and the HTTP router (seen before). One important task is monitoring. Understanding what is going on is vital in production deployment. The stats subsystem allows you to export uWSGI’s internal statistics as JSON: uwsgi --http :9090 --wsgi-file foobar.py --master --processes4 --threads2 --stats ,!127.0.0.1:9191 Make some request to your app and then telnet to the port 9191, you’ll get lots of fun information. You may want to use “uwsgitop” (just pip install it), which is a top-like tool for monitoring instances. Attention: Bind the stats socket to a private address (unless you know what you are doing), otherwise everyone could access it! 2.1.5 Putting behind a full webserver Even though uWSGI HTTP router is solid and high-performance, you may want to put your application behind a fully-capable webserver. uWSGI natively speaks HTTP, FastCGI, SCGI and its specific protocol named “uwsgi” (yes, wrong naming choice). The best performing protocol is obviously uwsgi, already supported by nginx and Cherokee (while various Apache modules are available). A common nginx config is the following: location/{ include uwsgi_params; uwsgi_pass 127.0.0.1:3031; } This means “pass every request to the server bound to port 3031 speaking the uwsgi protocol”. Now we can spawn uWSGI to natively speak the uwsgi protocol: uwsgi --socket 127.0.0.1:3031 --wsgi-file foobar.py --master --processes4 --threads ,!2 --stats 127.0.0.1:9191 If you’ll run ps aux, you will see one process less. The HTTP router has been removed as our “workers” (the processes assigned to uWSGI) natively speak the uwsgi protocol. If your proxy/webserver/router speaks HTTP, you have to tell uWSGI to natively speak the http protocol (this is different from –http that will spawn a proxy by itself): uwsgi --http-socket 127.0.0.1:3031 --wsgi-file foobar.py --master --processes4-- ,!threads2 --stats 127.0.0.1:9191 2.1.6 Automatically starting uWSGI on boot If you are thinking about firing up vi and writing an init.d script for spawning uWSGI, just sit (and calm) down and make sure your system doesn’t offer a better (more modern) approach first. 2.1. Quickstart for Python/WSGI applications 7 uWSGI Documentation, Release 2.0 Each distribution has chosen a startup system (Upstart, Systemd. ) and there are tons of process managers available (supervisord, god, monit, circus. ). uWSGI will integrate very well with all of them (we hope), but if you plan to deploy a big number of apps check the uWSGI Emperor - it is more or less the dream of every devops engineer. 2.1.7 Deploying Django Django is very probably the most used Python web framework around. Deploying it is pretty easy (we continue our configuration with 4 processes with 2 threads each). We suppose the Django project is in /home/foobar/myproject: uwsgi --socket 127.0.0.1:3031 --chdir /home/foobar/myproject/ --wsgi-file myproject/ ,!wsgi.py --master --processes4 --threads2 --stats 127.0.0.1:9191 (with --chdir we move to a specific directory). In Django this is required to correctly load modules. Argh! What the hell is this?! Yes, you’re right, you’re right. dealing with such long command lines is unpractical, foolish and error-prone. Never fear! uWSGI supports various configuration styles. In this quickstart we will use .ini files. [uwsgi] socket= 127.0.0.1:3031 chdir= /home/foobar/myproject/ wsgi-file= myproject/wsgi.py processes=4 threads=2 stats= 127.0.0.1:9191 A lot better! Just run it: uwsgi yourfile.ini If the file /home/foobar/myproject/myproject/wsgi.py (or whatever you have called your project) does not exist, you are very probably using an old (< 1.4) version of Django.
Load more

Recommended publications
  • Dynamic Web Pages with the Embedded Web Server
    Dynamic Web Pages With The Embedded Web Server The Digi-Geek’s AJAX Workbook (NET+OS, XML, & JavaScript) Version 1.0 5/4/2011 Page 1 Copyright Digi International, 2011 Table of Contents Chapter 1 - How to Use this Guide ............................................................................................................... 5 Prerequisites – If You Can Ping, You Can Use This Thing! ..................................................................... 5 Getting Help with TCP/IP and Wi-Fi Setup ............................................................................................ 5 The Study Guide or the Short Cut? ....................................................................................................... 5 C Code ................................................................................................................................................... 6 HTML Code ............................................................................................................................................ 6 XML File ................................................................................................................................................. 6 Provide us with Your Feedback ............................................................................................................. 6 Chapter 2 - The Server-Client Relationship ................................................................................................... 7 Example – An Analogy for a Normal HTML page .................................................................................
    [Show full text]
  • Effects and Opportunities of Native Code Extensions For
    Effects and Opportunities of Native Code Extensions for Computationally Demanding Web Applications DISSERTATION zur Erlangung des akademischen Grades Dr. Phil. im Fach Bibliotheks- und Informationswissenschaft eingereicht an der Philosophischen Fakultät I Humboldt-Universität zu Berlin von Dipl. Inform. Dennis Jarosch Präsident der Humboldt-Universität zu Berlin: Prof. Dr. Jan-Hendrik Olbertz Dekan der Philosophischen Fakultät I: Prof. Michael Seadle, Ph.D. Gutachter: 1. Prof. Dr. Robert Funk 2. Prof. Michael Seadle, Ph.D. eingereicht am: 28.10.2011 Tag der mündlichen Prüfung: 16.12.2011 Abstract The World Wide Web is amidst a transition from interactive websites to web applications. An increasing number of users perform their daily computing tasks entirely within the web browser — turning the Web into an important platform for application development. The Web as a platform, however, lacks the computational performance of native applications. This problem has motivated the inception of Microsoft Xax and Google Native Client (NaCl), two independent projects that fa- cilitate the development of native web applications. Native web applications allow the extension of conventional web applications with compiled native code, while maintaining operating system portability. This dissertation determines the bene- fits and drawbacks of native web applications. It also addresses the question how the performance of JavaScript web applications compares to that of native appli- cations and native web applications. Four application benchmarks are introduced that focus on different performance aspects: number crunching (serial and parallel), 3D graphics performance, and data processing. A performance analysis is under- taken in order to determine and compare the performance characteristics of native C applications, JavaScript web applications, and NaCl native web applications.
    [Show full text]
  • An Execution Model for Serverless Functions at the Edge
    An Execution Model for Serverless Functions at the Edge Adam Hall Umakishore Ramachandran Georgia Institute of Technology Georgia Institute of Technology Atlanta, Georgia Atlanta, Georgia ach@gatech:edu rama@gatech:edu ABSTRACT 1 INTRODUCTION Serverless computing platforms allow developers to host single- Enabling next generation technologies such as self-driving cars or purpose applications that automatically scale with demand. In con- smart cities via edge computing requires us to reconsider the way trast to traditional long-running applications on dedicated, virtu- we characterize and deploy the services supporting those technolo- alized, or container-based platforms, serverless applications are gies. Edge/fog environments consist of many micro data centers intended to be instantiated when called, execute a single function, spread throughout the edge of the network. This is in stark contrast and shut down when finished. State-of-the-art serverless platforms to the cloud, where we assume the notion of unlimited resources achieve these goals by creating a new container instance to host available in a few centralized data centers. These micro data center a function when it is called and destroying the container when it environments must support large numbers of Internet of Things completes. This design allows for cost and resource savings when (IoT) devices on limited hardware resources, processing the mas- hosting simple applications, such as those supporting IoT devices sive amounts of data those devices generate while providing quick at the edge of the network. However, the use of containers intro- decisions to inform their actions [44]. One solution to supporting duces some overhead which may be unsuitable for applications emerging technologies at the edge lies in serverless computing.
    [Show full text]
  • The Uch Enmek Example(Altai Republic,Siberia)
    Faculty of Environmental Sciences Institute for Cartography Master Thesis Concept and Implementation of a Contextualized Navigable 3D Landscape Model: The Uch Enmek Example(Altai Republic,Siberia). Mussab Mohamed Abuelhassan Abdalla Born on: 7th December 1983 in Khartoum Matriculation number: 4118733 Matriculation year: 2014 to achieve the academic degree Master of Science (M.Sc.) Supervisors Dr.Nikolas Prechtel Dr.Sander Münster Submitted on: 18th September 2017 Faculty of Environmental Sciences Institute for Cartography Task for the preparation of a Master Thesis Name: Mussab Mohamed Abuelhassan Abdalla Matriculation number: 4118733 Matriculation year: 2014 Title: Concept and Implementation of a Contextualized Navigable 3D Landscape Model: The Uch Enmek Example(Altai Republic,Siberia). Objectives of work Scope/Previous Results:Virtual Globes can attract and inform websites visitors on natural and cultural objects and sceneries.Geo-centered information transfer is suitable for majority of sites and artifacts. Virtual Globes have been tested with an involvement of TUD institutes: e.g. the GEPAM project (Weller,2013), and an archaeological excavation site in the Altai Mountains ("Uch enmek", c.f. Schmid 2012, Schubert 2014).Virtual Globes technology should be flexible in terms of the desired geo-data configuration. Research data should be controlled by the authors. Modes of linking geo-objects to different types of meta-information seems evenly important for a successful deployment. Motivation: For an archaeological conservation site ("Uch Enmek") effort has already been directed into data collection, model development and an initial web-based presentation.The present "Open Web Globe" technology is not developed any further, what calls for a migra- tion into a different web environment.
    [Show full text]
  • Uwsgi Documentation Release 1.9
    uWSGI Documentation Release 1.9 uWSGI February 08, 2016 Contents 1 Included components (updated to latest stable release)3 2 Quickstarts 5 3 Table of Contents 11 4 Tutorials 137 5 Articles 139 6 uWSGI Subsystems 141 7 Scaling with uWSGI 197 8 Securing uWSGI 217 9 Keeping an eye on your apps 223 10 Async and loop engines 231 11 Web Server support 237 12 Language support 251 13 Release Notes 317 14 Contact 359 15 Donate 361 16 Indices and tables 363 Python Module Index 365 i ii uWSGI Documentation, Release 1.9 The uWSGI project aims at developing a full stack for building (and hosting) clustered/distributed network applica- tions. Mainly targeted at the web and its standards, it has been successfully used in a lot of different contexts. Thanks to its pluggable architecture it can be extended without limits to support more platforms and languages. Cur- rently, you can write plugins in C, C++ and Objective-C. The “WSGI” part in the name is a tribute to the namesake Python standard, as it has been the first developed plugin for the project. Versatility, performance, low-resource usage and reliability are the strengths of the project (and the only rules fol- lowed). Contents 1 uWSGI Documentation, Release 1.9 2 Contents CHAPTER 1 Included components (updated to latest stable release) The Core (implements configuration, processes management, sockets creation, monitoring, logging, shared memory areas, ipc, cluster membership and the uWSGI Subscription Server) Request plugins (implement application server interfaces for various languages and platforms: WSGI, PSGI, Rack, Lua WSAPI, CGI, PHP, Go ...) Gateways (implement load balancers, proxies and routers) The Emperor (implements massive instances management and monitoring) Loop engines (implement concurrency, components can be run in preforking, threaded, asynchronous/evented and green thread/coroutine modes.
    [Show full text]
  • Interfacing Apache HTTP Server 2.4 with External Applications
    Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick November 6, 2012 Who am I? Interfacing Apache HTTP Server 2.4 with External Applications Met Unix (in the form of Xenix) in 1985 Jeff Trawick Joined IBM in 1990 to work on network software for mainframes Moved to a different organization in 2000 to work on Apache httpd Later spent about 4 years at Sun/Oracle Got tired of being tired of being an employee of too-huge corporation so formed my own too-small company Currently working part-time, coding on other projects, and taking classes Overview Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Huge problem space, so simplify Perspective: \General purpose" web servers, not minimal application containers which implement HTTP \Applications:" Code that runs dynamically on the server during request processing to process input and generate output Possible web server interactions Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Native code plugin modules (uhh, assuming server is native code) Non-native code + language interpreter inside server (Lua, Perl, etc.) Arbitrary processes on the other side of a standard wire protocol like HTTP (proxy), CGI, FastCGI, etc. (Java and \all of the above") or private protocol Some hybrid such as mod fcgid mod fcgid as example hybrid Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Supports applications which implement a standard wire protocol, no restriction on implementation mechanism Has extensive support for managing the application[+interpreter] processes so that the management of the application processes is well-integrated with the web server Contrast with mod proxy fcgi (pure FastCGI, no process management) or mod php (no processes/threads other than those of web server).
    [Show full text]
  • Python for Bioinformatics, Second Edition
    PYTHON FOR BIOINFORMATICS SECOND EDITION CHAPMAN & HALL/CRC Mathematical and Computational Biology Series Aims and scope: This series aims to capture new developments and summarize what is known over the entire spectrum of mathematical and computational biology and medicine. It seeks to encourage the integration of mathematical, statistical, and computational methods into biology by publishing a broad range of textbooks, reference works, and handbooks. The titles included in the series are meant to appeal to students, researchers, and professionals in the mathematical, statistical and computational sciences, fundamental biology and bioengineering, as well as interdisciplinary researchers involved in the field. The inclusion of concrete examples and applications, and programming techniques and examples, is highly encouraged. Series Editors N. F. Britton Department of Mathematical Sciences University of Bath Xihong Lin Department of Biostatistics Harvard University Nicola Mulder University of Cape Town South Africa Maria Victoria Schneider European Bioinformatics Institute Mona Singh Department of Computer Science Princeton University Anna Tramontano Department of Physics University of Rome La Sapienza Proposals for the series should be submitted to one of the series editors above or directly to: CRC Press, Taylor & Francis Group 3 Park Square, Milton Park Abingdon, Oxfordshire OX14 4RN UK Published Titles An Introduction to Systems Biology: Statistical Methods for QTL Mapping Design Principles of Biological Circuits Zehua Chen Uri Alon
    [Show full text]
  • User's Manual for Spatial Data Product Specification Description
    Technical Report of the Geographical Survey Institute A1-No.264 User's Manual for Spatial Data Product Specification Description May 2002 Preface to English Edition In Japan, the Geographical Survey Institute and private companies have jointly created and updated the Japanese Standards for Geographic Information (JSGI) in accordance with several standards in the draft stage to arrange implementation tests and utilization manuals since before the international standard based on ISO/TC211 si issued. User's Manual for Spatial Data Product Specification Description is created to spread the standards based on ISO/TC211 in Japan. This manual assumes that national organizations, local public organizations, and private companies use the ISO standards, and has the purpose that is different from that of ISO19131 Data Product Specifications. However, in order to help consider creating the standard for data product specifications or use the ISO standards in countries, this English version is created. The original of this manual is created from JSGI that is created in Japanese based on the draft standard created in English. Therefore, this English version is created through the processes of translation from English to Japanese, and from Japanese to English. Because of the time limit, the retranslated English technical terms are not examined carefully, and note that some terms are not correct. XML tag names are described alphabetically, but many of them are based on the Japanese alphabet (Roman character) notation instead of English because it is assumed that they are used in Japan. These tag names are not forcibly translated into English but "Note(E)" is appended to them.
    [Show full text]
  • NGINX-Conf-2018-Slides Rawdat
    Performance Tuning NGINX Name: Amir Rawdat Currently: Technical Marketing Engineer at NGINX inc. Previously: - Customer Applications Engineer at Nokia inc. Multi-Process Architecture with QPI Bus Web Server Topology wrk nginx Reverse Proxy Topology wrk nginx nginx J6 Technical Specifications # Sockets # Cores # Model RAM OS NIC per Threads Name Socket per Core Client 2 22 2 Intel(R) 128 GB Ubuntu 40GbE Xeon(R) CPU Xenial QSFP+ E5-2699 v4 @ 2.20GHz Web Server 2 24 2 Intel(R) 192 GB Ubuntu 40GbE Xeon(R) & Platinum Xenial QSFP+ Reverse 8168 CPU @ Proxy 2.70GHz Multi-Processor Architecture #1 Duplicate NGINX Configurations J9 Multi-Processor Architecture NGINX Configuration (Instance 1) user root; worker_processes 48 ; worker_cpu_affinity auto 000000000000000000000000111111111111111111111111000000000000000000000000111111111111111111111111; worker_rlimit_nofile 1024000; error_log /home/ubuntu/access.error error; ….. ……. J11 NGINX Configuration (Instance 2) user root; worker_processes 48 ; worker_cpu_affinity auto 111111111111111111111111000000000000000000000000111111111111111111111111000000000000000000000000; worker_rlimit_nofile 1024000; error_log /home/ubuntu/access.error error; ……. ……. J12 Deploying NGINX Instances $ nginx –c /path/to/configuration/instance-1 $ nginx –c /path/to/configuration/instance-2 $ ps aux | grep nginx nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx_0.conf nginx: worker process nginx: worker process nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx_1.conf nginx: worker process nginx: worker process
    [Show full text]
  • AJAX and Jquery L Raw AJAX Handling in JS Is Very Tedious L Jquery Provides Flexible and Strong Support to Handle AJAX Interactions Through a Set of Jquery Functions
    AJAX Asynchronous Design in Web Apps IT 4403 Advanced Web and Mobile Applications Jack G. Zheng Fall 2019 Topics l AJAX concepts and technical elements l AJAX implications and impacts l jQuery AJAX l Basic and shorthand methods l Error handling 2 AJAX l AJAX (Asynchronous JavaScript and XML) is a group of interrelated web development techniques used on the client-side to create interactive web applications. l Despite the name, the use of XML is not actually required, nor do the requests need to be asynchronous. 3 First Impression l https://www.google.com Use Chrome’s developer tools to view network communications while typing the search terms. A set of requests have been made to get JSON data from the server as I type in the search term box. Observe the “q” parameter in all URLs. 4 AJAX Model Difference With Ajax, web applications can communicate with servers in the background without a complete page loading after every request/response cycle. http://www.adaptivepath.com /ideas/ajax-new-approach- web-applications/ 5 Traditional Model The client does not generate views/presentations (HTML/CSS). Synchronous communications feature sequential request/response cycles, one after another The server prepares the whole page. http://www.websiteoptimization.com/secrets/ajax/8-1-ajax-pattern.html 6 Ajax Model l With Ajax, web applications can communicate with servers in the background without a complete page loading after every request/response cycle. The client generates views/presentations and update content (partial page) by manipulating DOM. Asynchronous communications feature independent request/response cycles The server prepares partial pages (partial HTML) or just data (XML or JSON).
    [Show full text]
  • Bepasty Documentation Release 0.3.0
    bepasty Documentation Release 0.3.0 The Bepasty Team (see AUTHORS file) Jul 02, 2019 Contents 1 Contents 3 1.1 bepasty..................................................3 1.2 Using bepasty’s web interface......................................4 1.3 Using bepasty with non-web clients...................................6 1.4 Quickstart................................................7 1.5 Installation tutorial with Debian, NGinx and gunicorn......................... 10 1.6 ChangeLog................................................ 12 1.7 The bepasty software Project....................................... 14 1.8 License.................................................. 14 1.9 Authors.................................................. 15 Index 17 i ii bepasty Documentation, Release 0.3.0 bepasty is like a pastebin for every kind of file (text, image, audio, video, documents, . ). You can upload multiple files at once, simply by drag and drop. Contents 1 bepasty Documentation, Release 0.3.0 2 Contents CHAPTER 1 Contents 1.1 bepasty bepasty is like a pastebin for all kinds of files (text, image, audio, video, documents, . , binary). The documentation is there: http://bepasty-server.readthedocs.org/en/latest/ 1.1.1 Features • Generic: – you can upload multiple files at once, simply by drag and drop – after upload, you get a unique link to a view of each file – on that view, we show actions you can do with the file, metadata of the file and, if possible, we also render the file contents – if you uploaded multiple files, you can create a pastebin with the list
    [Show full text]
  • Next Generation Web Scanning Presentation
    Next generation web scanning New Zealand: A case study First presented at KIWICON III 2009 By Andrew Horton aka urbanadventurer NZ Web Recon Goal: To scan all of New Zealand's web-space to see what's there. Requirements: – Targets – Scanning – Analysis Sounds easy, right? urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets What does 'NZ web-space' mean? It could mean: •Geographically within NZ regardless of the TLD •The .nz TLD hosted anywhere •All of the above For this scan it means, IPs geographically within NZ urbanadventurer (Andrew Horton) www.morningstarsecurity.com Finding Targets We need creative methods to find targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com DNS Zone Transfer urbanadventurer (Andrew Horton) www.morningstarsecurity.com Find IP addresses on IRC and by resolving lots of NZ websites 58.*.*.* 60.*.*.* 65.*.*.* 91.*.*.* 110.*.*.* 111.*.*.* 113.*.*.* 114.*.*.* 115.*.*.* 116.*.*.* 117.*.*.* 118.*.*.* 119.*.*.* 120.*.*.* 121.*.*.* 122.*.*.* 123.*.*.* 124.*.*.* 125.*.*.* 130.*.*.* 131.*.*.* 132.*.*.* 138.*.*.* 139.*.*.* 143.*.*.* 144.*.*.* 146.*.*.* 150.*.*.* 153.*.*.* 156.*.*.* 161.*.*.* 162.*.*.* 163.*.*.* 165.*.*.* 166.*.*.* 167.*.*.* 192.*.*.* 198.*.*.* 202.*.*.* 203.*.*.* 210.*.*.* 218.*.*.* 219.*.*.* 222.*.*.* 729,580,500 IPs. More than we want to try. urbanadventurer (Andrew Horton) www.morningstarsecurity.com IP address blocks in the IANA IPv4 Address Space Registry Prefix Designation Date Whois Status [1] -----
    [Show full text]