When I use tcpdump on a Linux Machine. Error happens:
$#/usr/sbin/tcpdump dst 183.131.XXX.XXX
tcpdump: can't create rx ring on packet socket: Cannot allocate memory
$#free -m
total used free shared buffers cached
Mem: 32111 30685 1426 0 4541 13533
-/+ buffers/cache: 12610 19501
BASIC INFO:
$#uname -a
Linu xxxx.xxxxxx.com 2.6.32_1-15-0-0 #1 SMP Fri Sep 01 15:37:59 CST 2010 x86_64 x86_64 x86_64 GNU/Linux
Who can help me? Thx a lot!
Related
I am running docker on GCP's container optimized os (through a VM). Is there any way to increase docker container disk space limitation?
Here is the results of uname -a
Linux instance-1 4.19.197+ #1 SMP Thu Jul 22 21:10:38 PDT 2021 x86_64 Intel(R) Xeon(R) CPU # 2.80GHz GenuineIntel GNU/Linux
Due to lack of permission I could not implement previous solutions on SO.
Please do as i do in your vps and then maybe the issue reproduced,replace the variable $vps_ip with your real vps ip during the below steps.
wget https://saimei.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
transmission-create -o debian.torrent debian-10.4.0-amd64-netinst.iso
Create a trackerless torrent ,show info on it:
transmission-show debian.torrent
Name: debian-10.4.0-amd64-netinst.iso
File: debian.torrent
GENERAL
Name: debian-10.4.0-amd64-netinst.iso
Hash: a7fbe3ac2451fc6f29562ff034fe099c998d945e
Created by: Transmission/2.92 (14714)
Created on: Mon Jun 8 00:04:33 2020
Piece Count: 2688
Piece Size: 128.0 KiB
Total Size: 352.3 MB
Privacy: Public torrent
TRACKERS
FILES
debian-10.4.0-amd64-netinst.iso (352.3 MB)
Open the port which transmission running on your vps.
firewall-cmd --zone=public --add-port=51413/tcp --permanent
firewall-cmd --reload
Check it from your local pc.
sudo nmap $vps_ip -p51413
Host is up (0.24s latency).
PORT STATE SERVICE
51413/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
Add the torrent and seed it with transmission's default username and password on your vps(with your own if you already change it):
transmission-remote -n "transmission:transmission" --add debian.torrent
localhost:9091/transmission/rpc/ responded: "success"
transmission-remote -n "transmission:transmission" --list
ID Done Have ETA Up Down Ratio Status Name
1 0% None Unknown 0.0 0.0 None Idle debian-10.4.0-amd64-netinst.iso
Sum: None 0.0 0.0
transmission-remote -n "transmission:transmission" -t 1 --start
localhost:9091/transmission/rpc/ responded: "success"
Get the debian.torrent from your vps into local pc.
scp root#$vps_ip:/root/debian.torrent /tmp
Now to try download it in your local pc.
aria2c --enable-dht=true /tmp/debian.torrent
06/08 09:28:04 [NOTICE] Downloading 1 item(s)
06/08 09:28:04 [NOTICE] IPv4 DHT: listening on UDP port 6921
06/08 09:28:04 [NOTICE] IPv4 BitTorrent: listening on TCP port 6956
06/08 09:28:04 [NOTICE] IPv6 BitTorrent: listening on TCP port 6956
*** Download Progress Summary as of Mon Jun 8 09:29:04 2020 ***
===============================================================================
[#a34431 0B/336MiB(0%) CN:0 SD:0 DL:0B]
FILE: /tmp/debian-10.4.0-amd64-netinst.iso
-------------------------------------------------------------------------------
I wait about one hour ,the download progress is always 0%.
If you're using DHT, you have to open a UDP port in your firewall and then, depending on what you're doing, you can specify that port to aria2c. From the docs:
DHT uses UDP. Since aria2 doesn't configure firewalls or routers for port forwarding, it's up to you to do it manually.
$ aria2c --enable-dht --dht-listen-port=6881 file.torrent
See this page for some more examples of using DHT with aria2c.
I'm trying to create a Docker image which will forward a port through a VPN. I've created a simple image which exposes port 5144, and tested that it works properly:
sudo docker run -t -d -p 5144:5144 \
--name le-bridge \
--cap-add=NET_ADMIN \
--device=/dev/net/tun \
bridge
sudo docker exec -it le-bridge /bin/bash
I check that the port is exposed correctly like this:
[CONTAINER] root#6116787b1c1e:~# nc -lvvp 5144
[HOST] user$ nc -vv 127.0.0.1 5144
Then, whatever I type is correctly echoed in the container's terminal. However, as soon as I start the openvpn daemon, this doesn't work anymore:
[CONTAINER] root#6116787b1c1e:~# openvpn logger.ovpn &
[1] 33
Sun Apr 5 22:52:54 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Sun Apr 5 22:52:54 2020 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Sun Apr 5 22:52:54 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]
Sun Apr 5 22:52:54 2020 UDPv4 link local (bound): [AF_INET][undef]:1194
Sun Apr 5 22:52:54 2020 UDPv4 link remote:
Sun Apr 5 22:52:54 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Apr 5 22:52:55 2020 [] Peer Connection Initiated with [AF_INET]
Sun Apr 5 22:53:21 2020 TUN/TAP device tun0 opened
Sun Apr 5 22:53:21 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Apr 5 22:53:21 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun Apr 5 22:53:21 2020 /sbin/ip addr add dev tun0 10.X.0.2/24 broadcast 10.X.0.255
Sun Apr 5 22:53:21 2020 Initialization Sequence Completed
root#6116787b1c1e:~#
root#6116787b1c1e:~# nc -lvvp 5144
listening on [any] 5144 ...
From here, using the exact same netcat command, I cannot reach the exposed port anymore from the host.
What am I missing?
EDIT: It's maybe worth mentioning that after the VPN is started, the connexion still succeeds from the host ; it just never reaches the netcat process inside the container.
I'm not exactly sure why, but it turns out that routes need to be fixed inside the container. In my case, the following command solves the issue:
ip route add 192.168.0.0/24 via 172.17.42.1 dev eth0
...where 172.17.42.1 is the IP of the docker0 interface on my host.
Hopefully this is helpful to someone one day.
I have been trying to get a OpenVPN client running with docker. But I got this error while setting up. My VPN provider is Private Internet Access. This is the Docker Image I used.
docker-compose up -d && docker logs -f openvpn
openvpn
openvpn
Creating openvpn
Wed Dec 18 02:17:32 2019 OpenVPN 2.4.7 armv6-alpine-linux-musleabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 6 2019
Wed Dec 18 02:17:32 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Wed Dec 18 02:17:32 2019 TCP/UDP: Preserving recently used remote address: [AF_INET][IP]:1197
Wed Dec 18 02:17:32 2019 UDP link local: (not bound)
Wed Dec 18 02:17:32 2019 UDP link remote: [AF_INET][IP]:1197
Wed Dec 18 02:17:32 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Dec 18 02:17:33 2019 [[LONG_RANDOM_STRING]] Peer Connection Initiated with [AF_INET][IP]:1197
Wed Dec 18 02:17:39 2019 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Wed Dec 18 02:17:39 2019 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Wed Dec 18 02:17:39 2019 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Wed Dec 18 02:17:39 2019 TUN/TAP device tun0 opened
Wed Dec 18 02:17:39 2019 /sbin/ip link set dev tun0 up mtu 1500
Wed Dec 18 02:17:39 2019 /sbin/ip addr add dev tun0 local [SHORTER_IP] peer [SHORTER_IP]
Wed Dec 18 02:17:39 2019 Initialization Sequence Completed
Wed Dec 18 02:17:49 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:17:59 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:18:05 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:18:05 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:18:15 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:18:25 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:18:35 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Dec 18 02:18:39 2019 [[LON_RANDOM_STRING]] Inactivity timeout (--ping-restart), restarting
Wed Dec 18 02:18:39 2019 SIGUSR1[soft,ping-restart] received, process restarting
Wed Dec 18 02:18:44 2019 TCP/UDP: Preserving recently used remote address: [AF_INET][IP]:1197
Wed Dec 18 02:18:44 2019 UDP link local: (not bound)
Wed Dec 18 02:18:44 2019 UDP link remote: [AF_INET][IP]:1197
Wed Dec 18 02:18:45 2019 [[LONG_RANDOM_STRING]] Peer Connection Initiated with [AF_INET][IP]:1197
Wed Dec 18 02:18:46 2019 AUTH: Received control message: AUTH_FAILED
Wed Dec 18 02:18:46 2019 SIGUSR1[soft,auth-failure (auth-token)] received, process restarting
These are the files I use:
[pia.ovpn]
client
dev tun
proto udp
remote [server].privateinternetaccess.com 1197
resolv-retry infinite
keepalive 10 60
nobind
persist-key
persist-tun
tls-client
remote-cert-tls server
auth-user-pass /vpn/vpn.auth
comp-lzo
verb 1
reneg-sec 0
redirect-gateway def1
disable-occ
fast-io
ca /vpn/ca.rsa.2048.crt
crl-verify /vpn/crl.rsa.2048.pem
vpn.auth contains my username and password. ca.rsa.2048.crt and crl.rsa.2048.pem I both got from this PIA support page.
Not sure if it is relevant, but this is the dockerfile I used.
version: '2'
services:
openvpn:
image: dperson/openvpn-client:armhf
container_name: openvpn
cap_add:
- net_admin
environment:
- TZ=[timezone]
networks:
- vpn
read_only: true
tmpfs:
- /run
- /tmp
restart: always
security_opt:
- label:disable
stdin_open: true
tty: true
volumes:
- /dev/net:/dev/net:z
- [PATH_TO]/vpn:/vpn
networks:
vpn:
I hope that someone sees what goes wrong here!
As I can see in your logs you've received Inactivity timeout (--ping-restart), restarting message after successfull connection in short period of time.
I had the same issue.
My client successfully connected and in few seconds (20-40) has been restarted.
In my case I've actually run two clients with the same client name (CN) on different hosts.
To fix it I've generated different clients for each host.
For me, the problem was using default PIA config. Once I switched to OPENVPN CONFIGURATION FILES (STRONG), the problem was gone.
You can find the configs at https://www.privateinternetaccess.com/helpdesk/kb/articles/where-can-i-find-your-ovpn-files-2, and if the link goes down, try googling "pia config".
I want to get all disk devices of host machine in Go or C++ language in a docker container. More information such as free spaces are also needed. What should I do or can this be possible ?
There is nothing special about Go or C++ that is required. You can use any relevant code or libraries that would examine Linux system devices for disk space or free space, because the environment the docker container provides is (typically) a Linux environment.
Docker Solution
docker run --privileged <image> <program> will populate the /dev file system in the container, which contains the device files relevant to your system and allows the container to access those devices.
User Solution
You will have to tell your users, e.g. in DockerHub documentation, or in error messages, to use the
--privileged flag
when running your image or it won't be able to access system devices.
You should expect some scrutiny or cynicism from some of your more knowledgeable users.
Like: why does it need that?
Details
According to Luc Juggery's blog on Medium:
Purpose of the --privileged flag
Running a container with the --privileged flag gives all the capabilities to the container and also access to the host’s devices (everything that is under the /dev >folder)...
However, he confuses the issue for beginners a bit by running docker from vagrant.
He also warns us:
If you use the --privileged flag when running a container, make sure you know what you are doing.
And I agree with that completely. Using --privileged gives the container the permission to modify the host.
It is easier to see what is happening from a Linux host running docker.
Example 1:
From the Linux host we will start an ubuntu container (without --privileged) and run sfdisk to see the disk partitions and ls -l /dev/s* to see the disk devices. It doesn't work because the container has no privileges to access the host in this way. The container's environment can not scan the disks on the host in any way.
paul#somewhere:~$ docker run -it ubuntu /bin/bash
root#175db156cb32:/# sfdisk --list
(blank output)
root#175db156cb32:/# ls -l /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory
Example 2:
Now we run docker run --privileged
paul#somewhere:~$ docker run --privileged -it ubuntu /bin/bash
root#c62b42161444:/# sfdisk --list
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EE70993B-4640-4899-B142-18B89DD16CB8
Device Start End Sectors Size Type
/dev/sda1 2048 923647 921600 450M Windows recovery environment
/dev/sda2 923648 1128447 204800 100M EFI System
/dev/sda3 1128448 1161215 32768 16M Microsoft reserved
/dev/sda4 1161216 467810878 466649663 222.5G Microsoft basic data
/dev/sda5 467812352 468858879 1046528 511M Windows recovery environment
Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 2F514662-72A3-4126-9868-40CEB6ADA416
Device Start End Sectors Size Type
/dev/sdb1 34 262177 262144 128M Microsoft reserved
/dev/sdb2 264192 5860532223 5860268032 2.7T Microsoft basic data
Partition 1 does not start on physical sector boundary.
Disk /dev/sdc: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x299c6114
Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 89843711 89841664 42.9G 83 Linux
/dev/sdc2 89843712 480468991 390625280 186.3G 83 Linux
/dev/sdc3 480471038 488396799 7925762 3.8G 5 Extended
/dev/sdc5 480471040 488396799 7925760 3.8G 82 Linux swap / Solaris
root#c62b42161444:/# ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Aug 11 02:43 /dev/sda
brw-rw---- 1 root disk 8, 1 Aug 11 02:43 /dev/sda1
brw-rw---- 1 root disk 8, 2 Aug 11 02:43 /dev/sda2
brw-rw---- 1 root disk 8, 3 Aug 11 02:43 /dev/sda3
brw-rw---- 1 root disk 8, 4 Aug 11 02:43 /dev/sda4
brw-rw---- 1 root disk 8, 5 Aug 11 02:43 /dev/sda5
brw-rw---- 1 root disk 8, 16 Aug 11 02:43 /dev/sdb
brw-rw---- 1 root disk 8, 17 Aug 11 02:43 /dev/sdb1
brw-rw---- 1 root disk 8, 18 Aug 11 02:43 /dev/sdb2
brw-rw---- 1 root disk 8, 32 Aug 11 02:43 /dev/sdc
brw-rw---- 1 root disk 8, 33 Aug 11 02:43 /dev/sdc1
brw-rw---- 1 root disk 8, 34 Aug 11 02:43 /dev/sdc2
brw-rw---- 1 root disk 8, 35 Aug 11 02:43 /dev/sdc3
brw-rw---- 1 root disk 8, 37 Aug 11 02:43 /dev/sdc5
root#c62b42161444:/# exit
and the docker container is allowed to access the host devices.