Some Name's questions

Ubuntu 22.04

Estou experimentando com IPv6pilha de protocolos no Linux e tentei descobrir quais protocolos são suportados como protocolos de camada L3 em cima de IPv6. De acordo com IANAeu executei o seguinte código simples para verificar a resposta de cada número de protocolo definido:

for i in range(1, 148):
    send(IPv6(src="::1", dst="::1", nh = i))
    sleep(1) 

No sudo tcpdump ip6 -n -vvv -i loI vejo que a maioria dos protocolos não são suportados, ou seja:

00:31:12.081361 IP6 (hlim 64, next-header unknown (37) payload length: 0)
   ::1 > ::1:  ip-proto-37 0
00:31:12.081371 IP6 (flowlabel 0x11111, hlim 64, next-header ICMPv6 (58) payload length: 48)
   ::1 > ::1: [icmp6 sum ok] ICMP6, parameter problem, next header - octet 6

Isso significa que a IPv6implementação da pilha de protocolos do Linux não entende o número do protocolo (nesse caso, era 37).

Os únicos números suportados além dos números de cabeçalhos de extensão eram:

TCP,     next header = 6
UDP,     next header = 17
ICMPv6,  next header = 58
PIM,     next header = 103
UDPLite, next header = 136

Note que even IPv6, next header = 41não foi reconhecido. Isso significa que IPv6a implementação do Linux não está em conformidade no sentido de RFC 8200?

Estou experimentando multicasto tráfego na minha rede sem fio e tentei executar ping em algum endereço multicast predefinido:

$ ping 224.0.0.251

O ipendereço da máquina de ping é 192.168.0.11. Então rodei tcpdumpem outra Linuxmáquina dentro da mesma LANe notei o seguinte:

$ sudo tcpdump -vv -n -i eth0 icmp
05:33:31.567847 IP (tos 0x0, ttl 1, id 23235, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.11 > 224.0.0.251: ICMP echo request, id 23235, seq 1, length 64
06:33:32.570106 IP (tos 0x0, ttl 1, id 42255, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.11 > 224.0.0.251: ICMP echo request, id 42255, seq 2, length 64

Como pode ser visto, os ICMPpacotes são recebidos naquele membro específico do grupo multicast, mas a ICMPresposta de eco não é enviada de volta. Por que? É possível configurá-lo para ser enviado?

CONFIG_IP_MULTICAST=yAtualmente estou aprendendo sobre IPmulticast e descobri que existem 2 protocolos multicast comuns para redes IP: PIM SSe PIM DS. Consultando as informações do meu adaptador wifi, descobri que o multicast é compatível:

$ ip link show dev wlp2s0 
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000

A questão é qual protocolo multicast o dispositivo usa?

Estou tentando criar um túnel via ssh e usá-lo como uma interface de rede regular. Aqui está o que eu tentei:

myuser@client-pc:

ip tuntap add mode tun user myuser name tun0
ip address add dev tun0 192.168.20.1/24
ip link set tun0 up

root@server-pc:

ip tuntap add mode tun user root name tun0
ip address add dev tun0 192.168.20.2/24
ip link set tun0 up

Mas ao tentar usar ssh -w tun0 root@server-pceu tenho

Bad tun device 'tun0'

A corrida -vvvmostra exatamente o mesmo. O que pode dar errado?

Linux Kernel 5.3

Considere o fstatsyscall definido como int fstat(int fd, struct stat *statbuf);. O acesso ao disco é necessário para o fstatsyscall no ext4?

Eu fiz algumas pesquisas relacionadas a ele e descobri algumas informações. O ponto de entrada no kernel para a chamada do sistema é a função vfs_statx_fd. Veja como fica sua implementação:

int vfs_statx_fd(unsigned int fd, struct kstat *stat,
         u32 request_mask, unsigned int query_flags)
{
    struct fd f;
    int error = -EBADF;

    if (query_flags & ~KSTAT_QUERY_FLAGS)
        return -EINVAL;

    f = fdget_raw(fd);
    if (f.file) {
        error = vfs_getattr(&f.file->f_path, stat,
                    request_mask, query_flags);
        fdput(f);
    }
    return error;
}

Então, o que temos aqui é que o unsigned int fddescritor de arquivo real que um usuário passou para a chamada do sistema é usado para encontrar um ponteiro para o arquivo struct file. A parte crucial de sua definição é

struct file {
    //...
    struct path     f_path;
    struct inode        *f_inode;   /* cached value */
    //...
}

Então, basicamente, temos que struct filerepresenta um arquivo aberto e o struct contém referências dentryeinode

É verdade que, caso tenhamos um descritor de arquivo aberto, podemos obter todas as estatísticas apenas da memória, evitando o dispendioso acesso ao disco?

Atualização : Tentei liberar os caches do Kernel free && sync && echo 3 > /proc/sys/vm/drop_caches && freeantes de invocar o syscalle isso não afetou o tempo do stat syscall. Então, eu tendo a pensar que nenhum acesso ao disco é necessário.

Eu tenho um sistema de automação de fluxo de trabalho que usa scripts python para executar um fluxo de trabalho definido neles. Estou montando um debpacote e estou em dúvida onde instalar esses scripts.

Atualmente estou em dúvida se devo colocá-los em /usr/lib/workflow_automateou /usr/share/workflow_automate.

Então ficaria algo assim:

/usr/share/workflow_automate/wf_script1.py
/usr/share/workflow_automate/wf_script2.py

UPD:

O sistema espera configurar uma variável de ambiente contendo um caminho para um arquivo de configuração. Espera-se que o arquivo de configuração contenha um caminho para um diretório no qual os scripts estejam contidos.

Existe um processo daemon do sistema de fluxo de trabalho que monitora as alterações nos diretórios configurados.

Estou construindo um pacote runtime-shared-library libfoo0.debonde 0aqui está uma versão principal do pacote e aderindo às convenções de nomenclatura especificadas na política Debian .

O problema é que eu quero construir outra biblioteca compartilhada libbardependendo do pacote de biblioteca compartilhada em tempo de execução libfoo0. Então estou pensando em adicionar uma estrofe depende, mas não tenho certeza se é necessário especificar uma versão, como

Depends: libfoo0 (= 0.0.4)

Aqui está a 0.0.4versão de libfoo0-dev.deb(pacote contendo arquivos de desenvolvimento/links simbólicos necessários em /usr/lib/) com a qual o arquivo libbarfoi construído. O problema que vejo é que proibiria os usuários de atualizar libfoo0.

Pergunta: Desde que olibfoo0binário seja compatível com versões anteriores da biblioteca principal, não é necessário especificar uma dependência na versão exata delibfoo0uma biblioteca/binário com a qual foi criada?

Estou lendo a seção de política do Debian no pacote de biblioteca compartilhada em tempo de execução e me deparei com a seguinte declaração:

Qualquer pacote que instale bibliotecas compartilhadas em um dos diretórios de bibliotecas padrão do vinculador dinâmico (que são atualmente /usr/libe /lib) ou em um diretório listado em /etc/ld.so.conf[5] deve ser usado ldconfigpara atualizar o sistema de bibliotecas compartilhadas.

Qualquer pacote desse tipo deve ter a linha activate-noawait ldconfigem seu arquivo de controle de gatilhos (ou seja, DEBIAN/triggers).

Estou curioso para saber o que pode acontecer se eu esquecer de adicionar esse gatilho. Atualmente, tenho um pacote dev instalado sem nenhum gatilho e um binário vinculado à biblioteca funciona muito bem.

Por que o requisito é importante?

Estou trabalhando em alguma biblioteca compartilhada e agora estou com o problema de que alguns softwares se recusaram a escolher a versão mais recente, mas alguns precisam usar a mais recente, pois tem algumas alterações cruciais. Então eu preciso manter 2 versões diferentes da mesma biblioteca.

O problema é que eu uso uma espécie de pacote "fat" libel.debque contém arquivos de cabeçalho necessários para desenvolvedores, bem como o binário real socompatível com os arquivos de cabeçalho. Estou pensando em dividir o libel.debem libel-dev.debe libel1-bin.deb, libel2-bin.deb.

Mas o problema é que libel-devcontém cabeçalhos compatíveis com a versão mais recente da biblioteca, então os desenvolvedores realmente precisam instalar 2 pacotes: libel-deve libel2-binque é propenso a erros (muito fácil de instalar deve binpacotes incompatíveis).

Como proceder nesta questão? Provavelmente é possível que o dev-package contenha binários também...?