Daniel Walker's questions

Estou desenvolvendo um aplicativo que estou enviando como uma imagem Docker. Meu aplicativo consiste em um único arquivo executável que vincula apenas com libc e libcrypto. Estou pensando em tornar minha imagem menor vinculando estaticamente o executável e colocando-o dentro de uma imagem de rascunho.

Meu problema vem do meu teste. Durante o teste, quero confirmar se meu aplicativo, que escuta em várias portas (TCP e UDP), se levantou corretamente. Tenho feito isso executando cat /proc/net/<file>via docker exec. No entanto, com uma imagem de rascunho, não terei acesso a catou mesmo sh.

Eu sei que eu poderia, durante o teste, lançar o BusyBox dentro do contêiner. No entanto, há uma maneira de examinar o sistema de arquivos proc usando apenas docker?

tentei

docker cp the_container:/proc/net/tcp .

mas deu erro

Resposta de erro do daemon: Não foi possível encontrar o arquivo /proc/net/tcp no contêiner the_container

Eu tenho um contêiner Docker iniciado via docker-compose. O arquivo de configuração especifica que deve fazer parte de duas redes. Entretanto, ocasionalmente (aproximadamente uma em cada cinco execuções), o contêiner é apenas membro de uma das redes (ou seja, docker network inspect <network_id>não mostra nenhum contêiner). Aqui está meu MRE:

Dockerfile

FROM alpine:latest

ENTRYPOINT ["sleep", "infinity"]

docker-compose.yaml

version: "3.7"

services:
  foo:
    image: foo
    init: true
    networks:
      - network1
      - network2

networks:
  network1:
  network2:

docker network inspect foo_network2mostra

[
    {
        "Name": "foo_network2",
        "Id": "2ef317904b46eddc3dcd8242f1ee41eff02756e016c701c2f2366bbbb166670e",
        "Created": "2024-03-12T04:15:24.57501242Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.144.0/20",
                    "Gateway": "192.168.144.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "network2",
            "com.docker.compose.project": "foo",
            "com.docker.compose.version": "2.24.6"
        }
    }
]

enquanto docker network inspect foo_network1mostra

[
    {
        "Name": "foo_network1",
        "Id": "a505fd52cd34c9ecdad1aa27058cc7cb47243d82283a7c7949b211be422a10e8",
        "Created": "2024-03-12T04:15:24.535686504Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.128.0/20",
                    "Gateway": "192.168.128.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "823f84eff688b9bc8e207b208cfb23852a2bc777b121107ab9d0ee48248e0b1d": {
                "Name": "foo-foo-1",
                "EndpointID": "37606efb0ea637c686edac7ccebab033dfd36f0cce9599d162a540a81d687b2f",
                "MacAddress": "02:42:c0:a8:80:02",
                "IPv4Address": "192.168.128.2/20",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "network1",
            "com.docker.compose.project": "foo",
            "com.docker.compose.version": "2.24.6"
        }
    }
]

Estou executando o Docker Desktop 4.28.0 (Engine 25.0.3, Compose: 2.24.6) em um Mac. Não consigo reproduzir esse comportamento no Ubuntu 23.10 (motor 25.0.2, docker-compose 1.29.2).

Tenho o Docker Desktop 4.25.2 em execução no meu Macbook. Depois de correr

docker network create foo
docker run --rm -it --network foo ubuntu:22.04 bash

Corri docker inspect <container_name>em outro terminal. Abaixo de "NetworkSettings", vejo

"Networks": {
    "foo": {
        "IPAMConfig": null,
        "Links": null,
        "Aliases": [
            "a3166231defa"
        ],
        "NetworkID": "21a369e01a3ba29ad63e8add84ca9a9aa167a3cfcb2dfe7747dfc9f18ed761b3",
        "EndpointID": "95b582ce02a4c15d452d36ede34b3ad3e3291c4e991049a384b296bd8096da4d",
        "Gateway": "192.168.0.1",
        "IPAddress": "192.168.0.2",
        "IPPrefixLen": 20,
        "IPv6Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "MacAddress": "02:42:c0:a8:00:02",
        "DriverOpts": null
    }
}

Vejo que o gateway é 192.168.0.1. No entanto, quando executo ifconfig | grep inetmeu host, não vejo esse endereço. Meu entendimento é que o host é sempre o gateway nas redes Docker.

Tenho dois contêineres Docker em execução (Ubuntu 22.04). Eles estão na mesma rede para que possam conversar entre si (verifiquei isso com nc). No primeiro contêiner, tenho um programa em execução que criou um dispositivo tun, atribuiu a ele um endereço IPv4 e o ativou. ip addrmostra

4: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 5.6.7.8/32 scope global tun0
       valid_lft forever preferred_lft forever
89: eth0@if90: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:c0:a8:30:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.48.2/20 brd 192.168.63.255 scope global eth0
       valid_lft forever preferred_lft forever

Meu programa então grava um pacote TCP SYN no dispositivo tun com um IP de origem 5.6.7.8 e um IP de destino 192.168.48.3 (o outro contêiner). No entanto, o pacote nunca chega ao outro contêiner. Já executei tcpdumpe o pacote aparece na tun0interface mas não no eth0. tcpdumpno outro contêiner não mostra nenhum pacote chegando.

Por que o pacote não seria roteado eth0?

Quando iniciei meus contêineres via docker-compose, configurei

sysctls:
  - net.ipv4.ip_forward=1

para o primeiro contêiner.

Eu também configurei o NAT:

iptables -I FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -I FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

Veja como recriar o que estou fazendo:

Arquivo Docker:

FROM ubuntu:22.04

RUN apt -y update && \
    apt -y install build-essential iptables tcpdump

WORKDIR /app 

emitir.c:

#include <arpa/inet.h>
#include <fcntl.h>
#include <linux/if_tun.h>
#include <net/if.h>
#include <netinet/in.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>

#define TUN_DEVICE "tun0"

#define SOURCE_IP "5.6.7.8"
#define DESTINATION_IP "192.168.48.3" // change to the actual address

unsigned char packet[] = {
    0x45, 0x00, 0x00, 0x54, 0x3a, 0x58, 0x40, 0x00, 0x40, 0x01, 0x03, 0x9d,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x48, 0xc1,
    0x00, 0x03, 0x00, 0x01, 0xa1, 0x81, 0x3a, 0x65, 0x00, 0x00, 0x00, 0x00,
    0x0d, 0x81, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x11, 0x12, 0x13,
    0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
    0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
    0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37
};

/*
Note: The IPv4 checksum will be wrong.  Run this program once and cause it to emit
the packet by sending the process SIGUSR1.  Capture the packet with tcpdump which
will tell you that the checksum is wrong and what it should be.  The result goes
at offset 10 in the packet.
*/

int tun_fd = -1;

void signal_handler(int signum)
{
    (void)signum;

    dprintf(STDOUT_FILENO, "Emitting packet\n");

    if ( write(tun_fd, packet, sizeof(packet)) < 0 ) {
        _exit(1);
    }
}


int set_address_and_bring_up(void)
{
    int ret = -1, sock;
    struct ifreq ifr = {.ifr_name = TUN_DEVICE};
    struct sockaddr_in addr = {.sin_family = AF_INET};

    inet_pton(AF_INET, SOURCE_IP, &addr.sin_addr);
    memcpy(&ifr.ifr_addr, &addr, sizeof(addr));

    sock = socket(AF_INET, SOCK_DGRAM, 0);
    if ( sock < 0 ) {
        perror("socket");
        return -1;
    }

    if ( ioctl(sock, SIOCSIFADDR, &ifr) == -1 ) {
        perror("ioctl (SIOCSIFADDR)");
        goto done;
    }

    ifr.ifr_flags = IFF_UP;
    if ( ioctl(sock, SIOCSIFFLAGS, &ifr) == -1 ) {
        perror("ioctl (SIOCSIFFLAGS)");
        goto done;
    }

    ret = 0;

done:
    close(sock);
    return ret;
}

int tun_device_create(void) {
    int fd;
    struct ifreq ifr = {.ifr_name = TUN_DEVICE, .ifr_flags = IFF_TUN | IFF_NO_PI};

    fd = open("/dev/net/tun", O_RDWR);
    if ( fd < 0 ) {
        perror("open");
        return -1;
    }

    if ( ioctl(fd, TUNSETIFF, &ifr) == -1 ) {
        perror("ioctl (TUNSETIFF)");
        goto error;
    }

    if ( set_address_and_bring_up() != 0 ) {
        goto error;
    }

    return fd;

error:
    close(fd);
    return -1;
}

int main() {
    struct sigaction action = {.sa_handler = signal_handler};

    inet_pton(AF_INET, SOURCE_IP, packet + 12);
    inet_pton(AF_INET, DESTINATION_IP, packet + 16);

    tun_fd = tun_device_create();
    if ( tun_fd < 0 ) {
        return 1;
    }

    sigaction(SIGUSR1, &action, NULL);

    while (1) {
        pause();
    }

    return 0;
}

iptables_script.sh:

#!/bin/sh -ex

iptables -I FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -I FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

Iniciando contêineres:

# First container
docker run --rm -it --cap-add NET_ADMIN -v $PWD:/app --device=/dev/net/tun my_image bash

# Second container
docker run --rm -it ubuntu:22.04 bash

Execute no primeiro contêiner:

test "`cat /proc/sys/net/ipv4/ip_forward`" -eq 1
gcc emit.c
./a.out &
./iptables_script.sh
kill -s USR1 `pgrep a.out`

Estou tentando instalar python3.9em um Dockerfile baseado em ubuntu:20.04. Quando executo apt -y install python3.9manualmente, ele solicita a área geográfica e a cidade correspondente ao meu fuso horário. Para mim, isso corresponde às opções 2 e 106 (ou seja, Nova Iorque), respectivamente. Porém, quando corro

echo '2\n106' | apt -y install python3.9

aptsaídas

Use of uninitialized value $_[1] in join or string at /usr/share/perl5/Debconf/DbDriver/Stack.pm line 111, <STDIN> line 1.

Current default time zone: '/UTC'

Como alimentei aptos valores de entrada corretamente?

Há um registro do Docker em execução na rede interna da minha empresa em, digamos, Registry.com. Eu sei que o registro é legítimo, mas quando eu corro

docker login registry.com

reclama que o certificado é assinado por uma autoridade desconhecida.

Existe uma maneira, na linha de comando, de baixar/construir o arquivo .crt para a autoridade para que eu possa adicioná-lo /usr/local/share/ca-certificatese executá- lo update-ca-certificates?

Sei que poderia adicionar o Registry.com, "insecure-registries"mas /etc/docker/daemon.jsongostaria de uma solução mais geral que não fosse específica do Docker.

No meu host Ubuntu 22.04, criei uma rede Docker com o driver de ponte e iniciei um contêiner nessa rede.

Executando ip addrno meu host, vejo essas duas interfaces:

5: br-fc7599764562: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:d4:4f:b9:39 brd ff:ff:ff:ff:ff:ff
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-fc7599764562
        valid_lft forever preferred_lft forever
    inet6 fe80::42:d4ff:fe4f:b939/64 scope link
        valid_lftforever preferred_lft forever
6: vethe6879a0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-fc7599764562 state UP group default
    link/ether e2:e8:0f:5b:37:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::e0e8:fff:fe5b:37a0/64 scope link
        valid_lft forever preferred_lft forever

Claramente, essas duas interfaces estão relacionadas, pois a segunda lista a primeira como "mestre". Qual é a relação?

Algum contexto para a pergunta: na verdade, tenho duas redes Docker com um contêiner dentro de cada uma. Usando o iptables, configurei o NAT entre eles (ou, pelo menos, acho que sim) e estou tentando fazer ping de um contêiner para o outro. Executando o Wireshark no host, vejo o pacote ICMP entrar na interface da ponte e sair na interface veth (em vez da outra ponte).

Meu objetivo é executar dois contêineres Docker em redes separadas e fazer com que meu host (Ubuntu 22.04) execute o NAT para que a primeira rede possa alcançar a segunda.

Minha configuração:

docker network create network1
docker network create network2

docker run --rm -it --network network1 ubuntu:22.04 bash

# In other terminal
docker run --rm -it --network network2 ubuntu:22.04 bash

O primeiro contêiner tem um endereço de 172.19.0.2 e o segundo tem um endereço de 172.20.0.2.

Executando ip addrem meu host, vejo que as interfaces são br-deadbeefe br-feedbeef, respectivamente.

eu então corro

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i br-deadbeef -o br-feedbeef -j ACCEPT
iptables -A FORWARD -i br-feedbeef -o br-deadbeef -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o br-feedbeef -j MASQUERADE

no host como root.

No entanto, ping 172.20.0.2desde o primeiro contêiner não é bem-sucedido. A execução do Wireshark no host mostra o pacote ICMP na br-deadbeefrede indo de 172.19.0.2 para 172.20.0.2, mas não há resposta.

o que estou perdendo?

Eu tenho uma VM Ubuntu 22.04 rodando via VirtualBox no meu MacBook. ip addrmostra (entre outras coisas):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

Dentro desta VM, eu corri

docker run --rm -it ubuntu:22.04 bash

Dentro do container, instalei net-toolse executei o ifconfig. A saída contida

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Por que não há endereço de loopback IPv6 no contêiner quando há um no host?

Eu tenho o zsh 5.8.1 rodando no Ubuntu 22.04. Quando tenho algum texto no prompt e digito Ctrl+ u, ele limpa a linha conforme o esperado. No entanto, quando eu digito Ctrl+ y, ele exibe apenas

$ ^Y

O que poderia estar fazendo com que o buffer readline não fosse colado?

Aqui está o meu .zshrc:

export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME=""

plugins=(
    colored-man-pages
    colorize
    git
    zsh-autosuggestions
    zsh-interactive-cd
    vi-mode
)

ZSH_AUTOSUGGEST_STRATEGY=(history completion)

source $ZSH/oh-my-zsh.sh
unalias ls
unalias ll
unalias lsa

unalias gst
alias gs='git status'
alias gcob='git checkout -b'

bindkey "^[[1;5C" forward-word
bindkey "^[[1;5D" backward-word
bindkey "^[." insert-last-word

_sig_array=($(kill -l))

_return_status() {
    ret=$?
    if [ $ret -ne 0 ]; then
        if [ $ret -le 128 ]; then
            echo $ret
        else
            sig=$(( $ret - 128 ))
            desc=$_sig_array[sig]
            if [ "$desc" != INT -a "$desc" != TSTP ]; then
                echo SIG$desc
            fi
        fi
    fi
}

_return_status_formatted() {
    out=$(_return_status)
    if [ -n "$out" ]; then
        echo "%F{red}[$out]%f "
    fi
}

_current_branch_formatted() {
    out=$(current_branch)
    if [ -n "$out" ]; then
        if [ -n "$(git status -s | grep -v '^\?')" ]; then
            color=magenta
        else
            color=cyan
        fi
        echo "%F{$color}(git:$out)%f "
    fi
}

export PS1='%F{blue}%n%f@%F{green}%m%f:%F{red}%~%f $ $(_return_status_formatted)$(_current_branch_formatted)'

Em um terminal, eu corri

$ nc -l -6 ::1 5000

Em outro terminal, corri

$ cat /proc/net/tcp6

e vi esta linha:

   0: 00000000000000000000000001000000:1388 00000000000000000000000000000000:0000 ...

Por que isso diz que estou ouvindo ::1:0:0:0e não ::1?

Estou SSH'ed em uma máquina virtual e procurando /proc/<pid>/net/tcpmeu shell zsh. eu vejo essa linha

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
 ...
 3: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 19127 1 0000000000000000 100 0 0 10 0

A menos que eu esteja entendendo mal o que isso está dizendo, o zsh está ouvindo na porta 22. Eu sei que o processo zsh é um descendente do processo que está executando o sshd, mas o sshd não teria fechado o soquete de escuta após a bifurcação?

Estou olhando para o resultado da execução ls -lem /proc/<pid>/fd/:

lr-x------ 1 root root 64 Apr 22 23:13 0 -> /dev/null
lrwx------ 1 root root 64 Apr 22 23:13 1 -> 'socket:[19700]'
lrwx------ 1 root root 64 Apr 22 23:13 2 -> 'socket:[19700]'
...

O que significam as permissões nos links simbólicos? A primeira coisa que me ocorre é que eles representam o "modo" dos descritores de arquivo. No entanto, se esse for realmente o caso, por que seria stdoutlegível? Além disso, por que todos os descritores seriam executáveis?

Estou tentando construir o Linux Kernel (versão 5.16). Eu sei que há uma opção de tempo de compilação para randomizar vários campos de estrutura (indicados por macros como randomized_struct_fields_start). No entanto, estou procurando make menuconfige não consigo encontrar a opção certa.

Estou tentando escrever um programa (em C) que, como um de seus recursos, percorre os procfs para encontrar soquetes abertos e verificar coisas como as portas/endereços de destino/origem (semelhante ao que netstat e lsof fazem). No entanto, não tenho certeza de qual chamada de sistema usar quando encontrar um arquivo de soquete. Por exemplo, suponha que eu liguei readlinke /proc/123/fd/4voltei socket:[56789]. O que posso fazer com essas informações, usando apenas a API do sistema, para obter os detalhes do soquete?

Eu tentei correr strace, netstatmas não está claro o que está acontecendo. Eu vejo um readligado /proc/123/fdinfo/4, mas não entendo do que se trata.

Por exemplo, o fdinfoarquivo para uma conexão aberta (conexão TCP para 127.0.0.1:5000) mostra

pos:    0
flags:  04002
mnt_id: 9

Eu escrevi anteriormente um script que pesquisa uma árvore de diretórios por arquivos .h e .c e, em seguida, executa o formato clang neles:

find $directory -name '*.[hc]' -exec clang-format -i {} \;

Isso funciona exatamente como esperado. Agora eu gostaria de adicionar arquivos .cpp à pesquisa. No entanto, nem

-name '*.{[hc],cpp}'

nem

-name '{*.[hc],*.cpp}'

trabalhar. Ou seja, eles não encontram arquivos.

Eu sei que eu poderia fazer minha lógica funcionar se eu usasse finda -oopção de . No entanto, deve haver uma maneira de fazer isso com uma única -namediretiva.

Eu tenho uma função definida na minha concha de peixe:

function cl --wraps=cd
    cd $argv && ls -l --color=auto
end

De acordo com man function, a --wrapsopção "faz com que a função herde as conclusões do comando encapsulado fornecido".

No entanto, quando digito cl e começo a completar a tabulação, são mostradas opções que incluem não-diretórios (como arquivos .c). No entanto, quando digito cd e concluo a tabulação, só são mostrados diretórios.

Eu defini minha função incorretamente?

Com minha concha de peixe, defini o alias

alias black='command black -l 110'

Quando digito blackno meu shell e começo a concluir a tabulação, recebo o erro

complete: profundidade máxima de recursão atingida

A mesma coisa acontece com aliases semelhantes, como

alias readelf='command readelf -W'