semvec/pypi-packages huggingface dataset:
iprecon 1.0.0
CLI tool that retrieves WHOIS data for IP addresses
Requires Python: >=3.10
Keywords: ip,whois,recon,security,bug-bounty

<h1 align="center">
  <img src="static/logo.png" width="60%" alt="iprecon">
  <br>
</h1>

<p align="center">
<a href="https://opensource.org/licenses/BSD-2-Clause"><img src="https://img.shields.io/badge/license-BSD%202--Clause-blue"></a>
</p>

<p align="center">
  <a href="#installation">Installation</a> •
  <a href="#usage">Usage</a> •
  <a href="#acknowledgements">Acknowledgements</a>
</p>

`iprecon` is a small CLI tool you can use to get WHOIS data for IP addresses which a focus on determining IP ownership.
Accepts lists of IPs from files or piped via stdin and outputs in different formats (textual table, CSV or JSON).
Output per IP is concise and kept to a single line for easy grepping and quick visual inspection.

# Installation

Run `pip install iprecon` to get it from [PyPI](https://pypi.org/).
Then run `iprecon --help` to see if it worked.

Alternatively, clone and install requirements from [requirements.txt](./requirements.txt)
(virtual environment highly recommended).

# Usage

To run `iprecon` you have to give it a list of IP addresses to check.
It expects simple lists with one IP per file.
Do it in two ways:
- from file: `iprecon --from-file /path/to/ips.txt`
- piped from stdin: `cat /path/to/ips.txt | iprecon`

You can output to different formats:
- `iprecon -o text`: outputs an ASCII table (terminal)
- `iprecon -o csv`: outputs a CSV file
- `iprecon -o json`: outputs a JSON file

Output is always printed to stdout.
Redirect to a file if required (e.g., `iprecon -o json > out.json` to store a JSON file).

Errors are ignored silently, e.g., if IPs have invalid formats or are private.
To see errors on stderr, request verbose output with `iprecon -v`.

WHOIS data can be requested in different ways.
Generally speaking, there is the legacy WHOIS protocol which is text-based and difficult to parse.
There is also RDAP, which is an HTTP-based protocol returning structured data.
See [here](https://www.arin.net/resources/registry/whois/rdap/) for more information.
By default, `iprecon` uses RDAP but if for any reason you get nonsense try if `iprecon --request-method whois` works better.

The tool is not fast and you may have to wait long when IP lists are large.
Try `iprecon --request-method rdap-bulk` in those cases, which tries to speed up but as much as possible but you may get banned.
There is also a delay because of setup so it will actually be slower on small lists.
You will also not get any intermediate output.
All results are shown at the end.

# Acknowledgements

`iprecon` is nothing more than a tiny wrapper around [github.com/secynic/ipwhois](https://github.com/secynic/ipwhois),
which is the library actually doing all the work.
Think of it as a command line interface to the library.
It has [nice documentation](https://ipwhois.readthedocs.io/en/latest/) you should read if you want to
know what is actually going on.
shuju-pai-thu-202211-202302 2023.2.16.0
数据派THU 202211-202302
Requires Python: >=3.6

# 数据派THU 202211-202302

## 下载

### Docker

```
docker pull apachecn0/shuju-pai-thu-202211-202302
docker run -tid -p <port>:80 apachecn0/shuju-pai-thu-202211-202302
# 访问 http://localhost:{port} 查看文档
```

### PYPI

```
pip install shuju-pai-thu-202211-202302
shuju-pai-thu-202211-202302 <port>
# 访问 http://localhost:{port} 查看文档
```

### NPM

```
npm install -g shuju-pai-thu-erlingereryiyi-erlingersanlinger
shuju-pai-thu-erlingereryiyi-erlingersanlinger <port>
# 访问 http://localhost:{port} 查看文档
```
mkdocs-modify-base-url 0.0.2
mkdocs plugin to control the base_url, for use with mike (for multiple versions) and i18n.
Requires Python: >=3.7

# mkdocs-modify-base-url

This mkdocs plugin is meant to be used with:

- [mkdocs-material](https://squidfunk.github.io/mkdocs-material/)
- [mike](https://github.com/jimporter/mike) for multiple versions of your documentation
- [multi-language documentation](https://github.com/squidfunk/mkdocs-material/discussions/2346)

The code in mkdocs-material that renders the version selection dropdown in the header dynamically requests
`versions.json` relative to the page's `base_url`. This works well normally, but when you try to add multiple
languages, things start to get a bit tricky.

I've set up my project documentation inside my repo like this:

```
.
├─ config/
│    ├─ en/
│    │  └─ mkdocs.yml
│    ├─ nl/
│    │  └─ mkdocs.yml
│    ├─ .../
│
├─ content/
│    ├─ en/
│    │   ├─ index.md 
│    │   └─ ...
│    └─ nl/
│        ├─ index.md 
│        └─ ,,,
│
├─ generated/
│    ├─ branch
│    │  ├─ en/
│    │  └─ nl/
│    └─ index.html
│
└─ ...
```

Each language has its own `mkdocs.yml`. Each is configured like this (only showing relevant parts, using `en` as 
  an example):

```yaml
docs_dir: '../../content/en'
site_dir: '../../generated/branch/en'
theme:
  language: en
extra:
  version:
    provider: mike
  alternate:
  - name: English
    link: en
    lang: en

plugins:
- modify-base-url:
    prefix: '../'
```

All languages are individually generated into `docs/generated/branch/$LANGUAGE`

There is a separate `mkdocs.yml` for `mike` to support versioning. There is really only one key, required setting, that
tells `mike` to use what we previously generated:

```yaml
docs_dir: generated/branch
```

When you run `mike deploy VERSION` from within the `docs` directory, it combines all the generated documentation for 
all the languages into a single version. There is also a static `index.html` file in `docs/generated/branch` that 
redirects initial requests to a default language.

Given a URL such as `docs.kcp.io/kcp/main/en`, when visiting `index.html`, its `base_url` is normally `.` because we 
told `mkdocs` to generate directly into the `en` directory. What's unique about this situation is that `mkdocs` 
thinks that one level up from `en` should be where `versions.json` lives. But it's actually up one more level, at
`docs.kcp.io/kcp/versions.json` because of our configuration.

And this is why this plugin exists. We need to adjust the `base_url` to move it up one more level, so instead of it 
being `.` for `docs.kcp.io/kcp/main/en/index.html`, it's actually `..`. Now, when `mkdocs-material` requests 
`base_url/../versions.json`, that becomes `../../versions.json`, which is really `docs.kcp.io/kcp/versions.json`.