Maestro's questions

Em sistemas de arquivos BTRFS você pode desabilitar o CoW para um arquivo usando o Catributo file, assim:

chattr +C filename

Eu esperava que isso funcionasse no ZFS também, já que também é um sistema de arquivos CoW, mas o atributo não pode ser definido (talvez o ZFS não possa funcionar sem o CoW).

Então, quais sistemas de arquivos suportam totalmente o Catributo file? Outros como XFS ou BCacheFS também respeitam esse sinalizador ou o BTRFS é o único sistema de arquivos que o faz?

Contexto: Criei um programa que instala uma máquina virtual, quando detecta que o sistema de arquivos host é BTRFS ele desabilita o CoW para a pasta com as imagens de disco virtual (caso contrário introduz problemas de desempenho). Apliquei o mesmo código ao ZFS, XFS e BCacheFS, mas tive que remover o ZFS porque ele não conseguiu definir o atributo. E agora fiquei em dúvida se preciso excluir o XFS e o BCacheFS também.

Eu tento fazer uma ioctl()chamada de bash. Isso é muito fácil de fazer em C, então existem ferramentas ( https://github.com/jerome-pouiller/ioctl ) que envolvem essa funcionalidade.

Mas isso dificultaria muito a distribuição do meu script, porque eu teria que distribuir essa ferramenta junto com ele.

Existe alguma outra ferramenta que já está incluída nos repositórios Debian APT que pode fazer o mesmo? Para que eu pudesse fazer um simples apt installa partir do script?

Antes de iniciar uma VM do meu script, preciso descobrir qual endereço IP ela obterá.

Então eu fiz:

dhclient <interface>

E isso funciona, porque dhclientusa o endereço MAC da macvtapinterface especificada e me retorna o endereço IP do servidor DHCP.

Essa não é uma solução infalível, pois pode haver algumas pessoas que tenham um roteador em casa que nem sempre retorna o mesmo IP para o mesmo MAC. Mas todos os roteadores que já tive funcionaram, então, se funcionar em 99% dos casos, é bom o suficiente para mim.

Mas o problema é que dhclienttambém faz alterações na configuração local porque acha que realmente quero usar esse endereço no host. Existe um -nsinalizador que deve impedir isso, mas não é suportado pelo Debian ou pela maioria das outras distribuições.

Então, qual é a melhor maneira de perguntar a um servidor DHCP qual IP ele está planejando servir para um determinado endereço MAC, sem realmente modificar nenhuma configuração no host?

Eu configurei uma interface macvtap assim:

ip link add link eth0 vlan type macvlan mode bridge
ip address add 10.0.0.17 dev vlan
ip link set dev vlan up
ip route flush dev eth0
ip route flush dev vlan
ip route add 10.0.0.0/24 dev vlan metric 0
ip route add default via 10.0.0.1
ip link add link eth0 name vtap address xx:xx:xx:xx:xx:xx type macvtap mode bridge
ip link set vtap up
ip address flush eth0
ip address flush vtap
dhclient -v vtap
ip address flush vtap

E funciona bem por algumas horas. Mas depois disso, todas as conexões com o IP do DHCP (macvtap) começarão a ir para a máquina host. Portanto, se eu me conectar ao IP na porta 80, por exemplo, verei uma página servida pelo host em vez da VM.

Estou tentando entender porque para de funcionar. A princípio, pensei que talvez a concessão do DHCP tivesse expirado e dhclientnão fosse renová-la. Mas o tempo de locação é de 24 horas, e esse problema começa antes disso, às vezes em menos de 10 horas.

Então, o que pode estar fazendo com que a macvtapinterface pare de funcionar?

Se eu fizer:

sleep 1 

contra

sleep 1 & wait $!

haverá alguma diferença em termos de uso da CPU para gerar um processo em primeiro plano versus um processo em segundo plano? Ou o desempenho de ambas as linhas será exatamente igual?

Eu tenho um serviço SysVinit muito simples em /etc/rc.d:

#!/bin/bash

PIDFILE="/var/run/test.pid"

status() {
  if [ -f "$PIDFILE" ]; then
    echo 'Service running'
    return 1
  fi
  return 0
}

start() {
  if [ -f "$PIDFILE" ] && kill -0 "$(cat "$PIDFILE")"; then
    echo 'Service already running'
    return 1
  fi
  echo 'Starting...'
  test & echo $! > "$PIDFILE"
  return 0
}

stop() {
  if [ ! -f "$PIDFILE" ] || ! kill -0 "$(cat "$PIDFILE")"; then
    echo 'Service not running'
    return 1
  fi
  echo 'Stopping...'
  kill -15 "$(cat "$PIDFILE")" && rm -f "$PIDFILE"
  return 0
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  status)
    status
    ;;
  restart)
    stop
    start
    ;;
  *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
esac

Quando o sistema inicia, ele inicia o serviço.

Mas quando o sistema para, ele nunca chama o comando stop. A única razão pela qual consigo pensar é que o sistema pensa que o serviço não está em execução ou não foi iniciado corretamente.

Mas quais são os requisitos para isso?

• Você precisa retornar um código de saída especial para o comando start?
• Preciso criar um arquivo em /var/lock/subsyspara sinalizar que está ativo?
• Mais alguma coisa que possa fazer com que o sistema pense que o serviço não foi iniciado?

Eu tenho um contêiner em uma rede em ponte. Ele pode alcançar o host sem problemas e conectar-se a todas as portas do host, EXCETO para portas que foram publicadas por outros contêineres.

Eu tenho o proxy userland desabilitado, então acho que pode ter algo a ver com a forma como o docker configura as regras do iptable.

Existe uma maneira simples de permitir que o contêiner alcance as portas publicadas por outros contêineres (executando em diferentes redes em ponte)?

Gostaria de evitar colocar os dois contêineres na mesma rede ou alternar para a rede de host.