Voor de echte helden..

[mupsje]

Beste Goeroes,

Ik heb 2 vraagjes over de "udm-pro Device Identification"

Vraag1:

Proxmox - LXC docker van tteck genaamd tinytuya.
deze wordt perfect weergegeven in de Unifi wanneer DHCP word geregeld door de UDM



wanneer ik een "static" ip in Proxmox geef dan zie ik enkel alleen het Mac address als naam.







Vraag 2:
Nu heb ik in deze LXC een docker met daarin een container draaiend via dockge

version: "3.8"
services:
  tinytuya:
    hostname: ttupdater
    stdin_open: true
    tty: true
    image: poepchen/backup-tinytuya:latest
    container_name: ttupdater
    environment:
      TZ: Europe/Amsterdam
      HOSTNAME: ttupdater.local
    networks:
      - dockervlan
    ports:
      - 6666:6666/udp
      - 6667:6667/udp
      - 7000:7000/udp
    restart: unless-stopped

networks:
  dockervlan:
    name: dockervlan
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.20.0/24
          ip_range: 192.168.20.248/29
          gateway: 192.168.20.1

als ik in de >_Bash command ga en ik type het volgende:

Zie je heel netjes de hostnames.

Waarom zie ik nu dan ook niet deze "hostname" terug in de UDM ?
Ik vind dit echt frustrerend.


Ik ben benieuwd of er een Goeroe is die mij duidelijkheid kan geven.

Heel veel dank alvast.

Mvg Mupsje

 

[Davey400]

Wat zie je wel bij die devices?
Alleen MAC?

 

[mupsje]

Wat zie je wel bij die devices?
Alleen MAC?

ja enkel alleen MAC

 

[Davey400]

Krijg je de hostnames wel terug als je een 3rd party tool gebruikt om deze aan het (virtuele) network device te vragen?

Mijn primaire clients zijn Windows en mijn kennis van Linux gebrekkig, maar vanuit Windows gebruik ik 2 methoden om op afstand een naam op te vragen als er geen losse tooling beschikbaar is:

ping -a <ip>
of:
nbtstat -A <ip>

In beide gevallen zou je een naam terug kunnen krijgen, maar ook niet altijd. De 1e 'vraagt' het aan het device, de 2e haalt het uit de Netbios cache.
Krijg je met deze acties wel een hostname?

(Ook nog wel van belang is of het om het principe gaat, of alleen om de herkenning in de UniFi interface; voor sommige device volsta ik simpelweg door het device in Network zelf van een naam te voorzien. Als je veel wisselende Dockers hebt is dat natuurlijk onhandig.)

 

[mupsje]

 

[Davey400]

Dan lijkt het er op dat de container zich naar buiten toe ook helemaal niet presenteert met die hostname.
Ik weet niet precies welke methode 'Network' gebruikt om de hostname te achterhalen, maar heel vreemd is het dus niet.
Ik heb helaas geen oplossing wegens totaal gebrek aan Docker kennis. Het kan wellicht nog een firewall-issue zijn op die container?
Meest logisch lijkt het me om te zorgen dat die container zijn naam op de één of andere manier wel adverteert, of zelfs actief publiceert in DNS.
(Het equivalent van ipconfig /registerdns in Windows).

Helaas; ik kan je niet verder helpen dan dit; je gaat toch afhankelijk zijn van de gezochte held; ik hoop dat er daar eentje van rond hangt hier.

 

[mupsje]

Dit maakt het duidelijker

OUI https://www.wireshark.org/tools/oui-lookup.html





Wanneer we dan de nieuwe stack via docker-compose een dhcpclient mee gaan installeren dan komt alles goed.
Maar eerst een Netwerk aanmaken, in de PVE - LXC - shell command.

docker network create -d macvlan \  --subnet=192.168.20.0/24 \  --gateway=192.168.20.1 \  -o parent=eth0 mymacvlan

Wanneer ik dan bijvoorbeeld deze commando meegeef in de docker-compose dan zien we hem wel verschijnen met de hostname.

version: "3.8"
services:
  debian_dhcp:
    image: debian:bookworm
    container_name: debian_dhcp
    hostname: debian_dhcp
    networks:
      mymacvlan: null
    cap_add:
      - NET_ADMIN
    command: >
      bash -c " apt update && apt install -y isc-dhcp-client && dhclient eth0 &&
      tail -f /dev/null "
networks:
  mymacvlan:
    external: true

de verklaring van de "Ubuntu" is hierboven al uitgelegd waarom dat is.

nu gaan we naar de static .

wanneer we naar static ip gaan dan zien we weer enkel alleen het MAC Address.



compose file:

version: "3.8"
services:
  debian_static:
    image: debian:bookworm
    container_name: debian_static
    hostname: debian_static
    networks:
      mymacvlan:
        ipv4_address: 192.168.20.9
    command: tail -f /dev/null
networks:
  mymacvlan:
    external: true

hoe lossen we dit op?
ook weer met dhclient. of met avahi dbus supervisor ( nog mee bezig)

We installeren even voor het gemaak ssh, nano en dhcp-client mee.
in ons nieuwe compose file:

version: "3.8"
services:
  debian_static:
    image: debian:bookworm
    container_name: debian_static
    hostname: debian_static
    networks:
      mymacvlan:
        ipv4_address: 192.168.20.11
    ports:
      - 22:22
    command: >
      bash -c " apt-get update && \ apt-get install -y openssh-server nano
      isc-dhcp-client && \ echo 'root:specialpassword' | chpasswd && \ sed -i -e
      's/#PermitRootLogin prohibit-password/PermitRootLogin yes/g' \ -e
      's/^PasswordAuthentication.*/PasswordAuthentication yes/' \
      /etc/ssh/sshd_config && \ ssh-keygen -A && \ service ssh start && \ tail
      -f /dev/null "
networks:
  mymacvlan:
    external: true

nu kunnen we inloggen via SSH

ssh root@192.168.20.11

password is the one in `` echo 'root:specialpassword' ``

then we need to change the dhclient config file.

nano /etc/dhcp/dhclient.conf

change sent host-name to

send host-name = "debian_static";[/code[

then save and we reboot the netwerk interface.

[code] dhclient -v eth0

En Tada,,,,,,,,



Nu behoor ik ook tot de Goeroes dan

Ik ga mij ook nog even verdiepen in de avahi

Groetjes Mupsje