arineng / arincli Goto Github PK

Ruby commands for ARIN's Reg-RWS and Whois-RWS

License: Apache License 2.0

Ruby 99.94% Shell 0.03% HTML 0.03%

arincli's Introduction

arincli -- ARIN Command Line Interface

DESCRIPTION

ARINcli is a set of command line scripts, written in Ruby, that utilize both the Whois-RWS service and the Reg-RWS service. Whois-RWS is ARIN's Whois/NICNAME RESTful web service for exposing IP network and ASN registration data to the public (Note this service pre-dates the IETF WEIRDS/RDAP service and is not yet compatible with that specification). Reg-RWS is ARIN's registration RESTful web service available to customers of ARIN.

At the time of this writing, the ARINcli scripts should be considered beta quality. A lot of functionality is still missing from the scripts, and ARIN has not conducted any degree of quality assurance against them.

COMMANDS

arininfo queries ARIN's Whois-RWS service.
poc creates, modifies, and deletes Point of Contacts (POCs).
rdns modifies reverse DNS delegations.
ticket downloads, displays and manages Reg-RWS tickets.
arinreports requests reports from ARIN using Reg-RWS.
arinutil is a utility for managing ARINcli scripts.

CONFIGURATION

The ARINcli commands all use an application data directory to store configuration files, caches, etc. The arinutil(1) command can be used to manipulate the caches and configuration. This application data directory is $HOME/.ARINcli for Unix and Unix-like systems, and %APPDATA%\ARINcli for Windows. This directory is created automatically the first time an ARINcli command is run.

Configuration is kept in the config.yaml file in the application data directory. This is a YAML file and so YAML syntax is required. YAML is designed to be human friendly yet machine parsable. For users of Reg-RWS, the API Key given will likely need be changed to the users real API key. An API Key can be obtained via ARIN Online. An API Key is not needed for Whois-RWS.

INSTALLATION

At present, there are two ways to install this code: 1) via a Git clone from GitHub, or 2) from a zip file release on GitHub.

The ARINcli commands are Ruby programs, and Ruby 1.8.7 and above are needed.

To verify compatibility and that everything is working, run the tests with the run_all_tests command.

To build the man pages and these documents, you must use ronn. You can install it as a Ruby gem with gem install ronn. Once it is installed, build the man pages with the following command: ronn man/*.ronn.

HELP

Questions and comments regarding this software may be directed to ARIN's Technical Discussion mailing list ([email protected]). Archives and subscription information are available at http://lists.arin.net/pipermail/arin-tech-discuss/.

arincli's People

Contributors

Stargazers

Watchers

Forkers

evgeniy175 allo-com-eng loganmurphy ilebrero dqhx njcaruso mmnemonic vans163 demoore hazemehsan paurb wpadala420 quarterback wjy-norainu dapizzamon22 sszfcdxcxsa aaronslin jsajal anqini mtho620 therealmurders rakurati michaelgatuma maxbremer mskycoder shazotihashimoto towliedb lukemellor95 chancemckinney connorcote314 wificlonehf sergsera gregorylearns james-owen-ryan somehoodrat artslidd backtohomepage segoeui megfitz95 edbltn noahc77 brandon0329 alexandretran stealth-coder gdento anewton1998 adithyavh pacifico modulexcite shauli-ravfogel cloudymushrooms cysion gacho1 smiffy119 paddyfrenchman taii-taii markuspinter karolpi hkdhaka ncorbuk anuragtom https-github-com-tigareksaperdana-co-id soumya-sr thielm sitedata venn0m c0decat fabioromeiro rcastellanes daniel-jelenici seppedewitte asturm0 hemestal benkraw ronyzarom shawsey sagemods fedepiz joaquinrcamara vistocity kbots-tech nevindu brend3n matthewmyrick jianderson xt-riot mrinal1894 diedb asedwse danmayor ca9ha romaloginovskiy elliotkantor yagisanatode rouslansv elyskrie21 iamthatiam777 yourlastmemory herytahina ygasaino1

arincli's Issues

ありあー

/rest/customer/CUSTOMERHANDLE?apikey=APIKEY

I just read that Microsoft is acquiring GitHub. I have seen enough of Microsoft love for open source for a life time to avoid everything that involves them. It is at best just a kiss of death and soon all users are required to install Microsoft malware and open Microsoft accounts to use GitHub, all all our information is for sale. I am quitting GitHub. So long and thanks for all the fish.

I just read that Microsoft is acquiring GitHub. I have seen enough of Microsoft love for open source for a life time to avoid everything that involves them. It is at best just a kiss of death and soon all users are required to install Microsoft malware and open Microsoft accounts to use GitHub, all all our information is for sale. I am quitting GitHub. So long and thanks for all the fish.

オリジナルは @ghost が acmesh-official/acme.sh#1655 にポスト

た

オリジナルは @Hayato5648 が WrathLi/iOS_WIFI_Information#3 にポスト

な

オリジナルは @Hayato5648 が Feghal/FGRoute#10 にポスト

さ

か

オリジナルは @Hayato5648 が rmbrone/rmbr_ip#4 にポスト

No license information in repo

Just to make it clear to everyone else, there should be a file to say which license all the code is (GPL, BSD, etc.).

<!--

Output of docker version:

Client:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 2
 Running: 0
 Paused: 0
 Stopped: 2
Images: 1
Server Version: 1.12.0-rc3
Storage Driver: zfs
 Zpool: tank
 Zpool Health: ONLINE
 Parent Dataset: tank/docker
 Space Used By Parent: 98304
 Space Available: 7621296459776
 Parent Quota: no
 Compression: lz4
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.22.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.7 GiB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):

The machine is physical, running Centos 7.2.1511 with ZoL v0.6.5.7-1.

Steps to reproduce the issue:

Start docker 1.12.0-rc3, with a ZFS volume mounted at /var/lib/docker
Create a simple Dockerfile

mkdir /tmp/docker-simple
cat << EOF > /tmp/docker-simple/Dockerfile
FROM alpine:latest
RUN echo testing > /tmp/testing
EOF

Build it

docker build -t local/simple /tmp/docker-simple

Describe the results you received:

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM alpine:latest
 ---> 4e38e38c8ce0
Step 2 : RUN echo testing > /tmp/testing
 ---> Running in 7553774d9301
error creating zfs mount of tank/docker/73360b9c302e91614ac2b1727d161fb8fdc42b49903f8211ed4356f0fecf8b8b to /var/lib/docker/zfs/graph/73360b9c302e91614ac2b1727d161fb8fdc42b49903f8211ed4356f0fecf8b8b: device or resource busy

Describe the results you expected:
When performing the same actions on 1.12.0-0.2.rc2 the build completes successfully.

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM alpine:latest
 ---> 4e38e38c8ce0
Step 2 : RUN echo testing > /tmp/testing
 ---> Running in a518cd368625
 ---> 09a63abb1159
Removing intermediate container a518cd368625
Successfully built 09a63abb1159

Additional information you deem important (e.g. issue happens only occasionally):
The issue occurs on every attempt, I've also noticed that I cannot start the docker daemon on RC3 until I manually create the /var/lib/docker/zfs directory.

DEBU[0001] [zfs] ID:cab1bc32-09bb-47d1-b73b-80f48a694dc5 START zfs list -rHp -t filesystem -o name,origin,used,available,mountpoint,compression,type,volsize,quota,written,logicalused,usedbydataset tank/docker
DEBU[0001] [zfs] ID:cab1bc32-09bb-47d1-b73b-80f48a694dc5 FINISH
DEBU[0001] Cleaning up old mountid : start.
FATA[0001] Error starting daemon: error initializing graphdriver: no such file or directory

It seems to mount the /var/lib/docker/zfs directory to the same zfs volume as /var/lib/docker, a process that wasn't occurring in previously. Output from RC2,

# mount | grep docker
tank/docker on /var/lib/docker type zfs (rw,noatime,seclabel,xattr,noacl)

and in RC3

# mount | grep docker
tank/docker on /var/lib/docker type zfs (rw,noatime,seclabel,xattr,noacl)
tank/docker on /var/lib/docker/zfs type zfs (rw,noatime,seclabel,xattr,noacl)

A similar issue occurs after a container is removed, however this is intermittent.

# docker run -it --rm alpine ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=60 time=1.234 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.234/1.234/1.234 ms
Error response from daemon: Driver zfs failed to remove root filesystem 208e64b201ea674d56d6028882f45a574aaa31dc2826ea21eaaa204b85161564: exit status 1: "/sbin/zfs zfs destroy -r tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7" => cannot destroy 'tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7': dataset is busy

DEBU[0051] Calling DELETE /v1.24/containers/208e64b201ea674d56d6028882f45a574aaa31dc2826ea21eaaa204b85161564?force=1&v=1
DEBU[0051] [zfs] ID:24f591d3-6ec2-4bdd-b502-be6e55ea1e6d START zfs destroy -r tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7
DEBU[0051] [zfs] ID:24f591d3-6ec2-4bdd-b502-be6e55ea1e6d FINISH
ERRO[0051] Error removing mounted layer 208e64b201ea674d56d6028882f45a574aaa31dc2826ea21eaaa204b85161564: exit status 1: "/sbin/zfs zfs destroy -r tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7" => cannot destroy 'tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7': dataset is busy

ERRO[0051] Handler for DELETE /v1.24/containers/208e64b201ea674d56d6028882f45a574aaa31dc2826ea21eaaa204b85161564 returned error: Driver zfs failed to remove root filesystem 208e64b201ea674d56d6028882f45a574aaa31dc2826ea21eaaa204b85161564: exit status 1:
"/sbin/zfs zfs destroy -r tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7" => cannot destroy 'tank/docker/ecd5729475a065a7d3ef71e1cdfef73c2e09e4099faf37ab12e1bc5274b78bc7': dataset is busy

オリジナルは @dsau が moby/moby#24403 にポスト

ち

オリジナルは @Hayato5648 が dklinzh/DLNWiFiDetector#2 にポスト

Reported bugs must reproducible in the context described in the "Context" section.

Installation and configuration issues are not bugs, but individual assistance request.

Context: the LATEST version of dnscrypt-proxy (precompiled binaries downloaded from this repository) is correctly installed and configured on your system, but something doesn't seem to produce the expected result.

If the bug is not trivial to reproduce on any platform, please include ALL the steps required to reliably duplicate it, on a vanilla, generic install of macOS, Windows, OpenBSD or Ubuntu Linux system, in their most current version.

If you don't have any clear understanding of the issue or can't enumerate the steps to reproduce it, open a discussion instead:
https://github.com/DNSCrypt/dnscrypt-proxy/discussions

Output of the following commands:

$ dnscrypt-proxy -version
2.1.0

$ dnscrypt-proxy -config ~/.config/dnscrypt/dnscrypt-proxy.toml -check
[2021-09-10 14:38:52] [NOTICE] dnscrypt-proxy 2.1.0
[2021-09-10 14:38:52] [NOTICE] Source [public-resolvers] loaded
[2021-09-10 14:38:52] [NOTICE] Source [relays] loaded
[2021-09-10 14:38:52] [NOTICE] Configuration successfully checked

$ dnscrypt-proxy -config ~/.config/dnscrypt/dnscrypt-proxy.toml -resolve git.xxx.mycompany.com
Resolving [git.xxx.mycompany.com] using 127.0.0.53 port 53

Resolver : 103.107.xxx.xxx

Canonical name: gitlab.xxxx.xxxx.mycompany.com.

IPv4 addresses: 100.111.xxx.xx
IPv6 addresses: -

Name servers : no name servers found
DNSSEC signed : no
Mail servers : no mail servers found

HTTPS alias : -
HTTPS info : -

Host info : -
TXT records : -

Initially raised as discussion #...

What is affected by this bug?

ping ssh etc

ssh [email protected]
ssh: Could not resolve hostname git.xxx.mycompany.com: Temporary failure in name resolution

ping git.cec.mycompany.com
ping: git.cec.mycompany.com: Temporary failure in name resolution

When does this occur?

This occurs when the query is sent to forwarding server using forwarding rules

#forwarding rule
mycompany.com 201.xxx.xx.1,201.xxx.xx.2

Where does it happen?

This occurs when the query is sent to forwarding server

$ nslookup git.xxx.mycompany.com
;; Truncated, retrying in TCP mode.
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
git.xxx.mycompany.com canonical name = gitlab.xxx.xxx.mycompany.com.
Name: gitlab.xxx.xxx.mycompany.com
Address: 100.111.xxx.xx

How do we replicate the issue?

Add a forward rule like
mycompany.com 201.xxx.xx.1,201.xxx.xx.2

Expected behavior (i.e. solution)

ssh [email protected]
ping git.xxx.mycompany.com

should work

Other Comments

The same server with ping, ssh etc using dns lookup using the 201.xxx.xx.1 directly in /etc/resolv.conf works fine.
nameserver 201.xxx.xx.1
nameserver 127.0.0.53
And I do not want to use systemd-resolv.

Why the forwarding server rule is working but throwing ";; Truncated, retrying in TCP mode." ?
I am not sure if this is the cause of the problem.
If I specify the same hostname ip rule in cloaking then there is no problem, but that does not serve the purpose of looking up dns servers in forward servers.

Attached the sample response for forward server.
dig.txt

オリジナルは @piyushgarg が DNSCrypt/dnscrypt-proxy#1873 にポスト

The venerable [dnscrypt-osclient](https://github.com/alterstep/dnscrypt-osxclient/) hasn't received any updates for a while, and the interface would not work well for dnscrypt-proxy v2.

The venerable dnscrypt-osclient hasn't received any updates for a while, and the interface would not work well for dnscrypt-proxy v2.

A new client for macOS is really needed.

Can anybody help?

オリジナルは @jedisct1 が DNSCrypt/dnscrypt-proxy#47 にポスト

Currently, if 'docker' driver is used, `minikube delete --all --purge` command does not remove the pulled kicbase image

Currently, if 'docker' driver is used, minikube delete --all --purge command does not remove the pulled kicbase image

➜  minikube git:(master) ✗ out/minikube start --driver=docker
* minikube v1.18.0 on Darwin 11.2
* Using the docker driver based on user configuration
* Starting control plane node minikube in cluster minikube
* Pulling base image ...
* Creating docker container (CPUs=2, Memory=3890MB) ...
* Preparing Kubernetes v1.20.2 on Docker 20.10.3 ...
  - Generating certificates and keys ...
  - Booting up control plane ...
  - Configuring RBAC rules ...
* Verifying Kubernetes components...
  - Using image gcr.io/k8s-minikube/storage-provisioner:v4
* Enabled addons: default-storageclass, storage-provisioner
* Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

➜  minikube git:(master) ✗ docker images | grep kicbase
gcr.io/k8s-minikube/kicbase                           v0.0.18                           a776c544501a   5 days ago      1.08GB


➜  minikube git:(master) ✗ out/minikube delete --all --purge
* Deleting "minikube" in docker ...
* Removing /Users/izuyev/.minikube/machines/minikube ...
* Removed all traces of the "minikube" cluster.
* Successfully deleted all profiles
* Successfully purged minikube directory located at - [/Users/izuyev/.minikube]

➜  minikube git:(master) ✗ docker images | grep kicbase     
gcr.io/k8s-minikube/kicbase                           v0.0.18                           a776c544501a   5 days ago      1.08GB

This can be unexpected for user. For example, if he/she is using the locally built kicbase image and wants to reset it to the official one. --purge could be interpreted as remove everything related.

May be we should delete the image or, if not, print an explicit warning/info message that we keep it when running minikube delete

オリジナルは @ilya-zuyev が kubernetes/minikube#10708 にポスト