[Eisfair] e64 - Neuinst. - DHCP - Netzwertkproblem - Nextcloud

Sa Mai 25 00:17:44 CEST 2019

Hallo,

Folgendes Phänomen bei einer Eisfair-Neuinstallation:

Gegeben:
QUEMU/KVM, Debian 9, als vHost

Darauf Neu-Installation einer VM mit diesem Installationsimage:
eisfair-2.8.14-3.38.1-VIRT-x86_64-cd-image.iso (aktueller Download)

Weiters:
1. DHCP/DNS-Server (RPI3B, Alpine 3.9.x mit "dnsmasq" als DHCP/DNS_Server-SW), IP 192.168.0.6,aktiv
    vergibt an "Clients": DHCP dynamische IP-Addr-Range: 192.168.0.100-120
                          IP-Adressen, die die Clients eintragen: 1
    DHCP/dnsmasq stellt als weitere Information für Clients bereit:
	dhcp-option=6.192.168.0.6,192.168.0.5 --> genau in dieser Reihenfolge (.6=aktiv, .5 inaktiv)
	zusätzlich werden noch Default-GW und DOMAIN_Name bereitgestellt, Broadcast-Addr, Subnet_Mask.

2. DHCP/DNS-Server (nativer E1-Server, aktuelle SW, DHCP+DNS-SW), IP 192.168.0.5, DHCPD in-aktiv, Fallback.
    DHCPD-Info analog 1.

Neuinstallation mit als Eisfair-64 VM (1024M mem./ 5G vHD, als Testsystem).
Nach 1. Neustart hat die VM erhält die VM via udhcpc die bereitgestellten Netzwerk-Informationen Information und macht daraus 
folgende Netzwerkeinstellungen (s. setup-1-1-1):

	IP_ETH_1_NAME='net0'
	IP_ETH_1_IPADDR='192.168.0.101 --> IP-ADDR aus DHCP-Adress-Range

	DOMAIN_NAME='<Domain Name>'  --> vom DHCP-Server
	DNS_Server='192.168.0.5 --> vom DHCP Server. .5 ist die Adresse des _2._ DHCP/DNS-Servers

Damit kann ich noch kein Netzwerk und keine DNS-Adresse verwenden, somit ist auch - ohne weitere Konfigurationen - noch kein 
eisman update/upgrade und keine weitere Installation (von Packeis) möglich.

Abgesehen davon dass 'net0' auf die gültige 'enx<MacAddr>' geändert werden muss, wird nur die _2._ DNS-Server-Adresse 
eingetragen und auch nur _1_ DNS-Server-Adresse. Die 1. DNS-Server-Adresse (.6) fehlt. Die o.g. Reihenfolge der DNS-Adressen 
s.o. ist absichtlich so gewählt.

Meine Frage ist, warum die Eisfair-Installation nicht beide DNS-Adressen korrekt eintragen kann. Es ist nämlich möglich, 2 
DNS-Serveradressen - mit Leerzeichen getrennt - in DNS_SERVER einzutragen.

Darüber, dass - aus technischen Gründen? - nicht auch gleich der richtige Netzwerk-Devicename (enx...) eingetragen wird, hatten 
wir vor einiger Zeit, glaub ich, schon mal gesprochen. Es war/ist irgendwie nicht möglich. Ich erinnere es nicht mehr.

Ich weiss nur, dass alle meine Linux-basierten Systeme, die ich betreibe bzw. installiert habe (Debian, Ubuntu, ArchLinux, 
Alpine, openSUSE u.a.) und auch Windows 10, MACOS, NetBSD das können. Da sind immer beide DNS-Server in der resolv.conf 
eingetragen und die korrekten Netzwerk-Devicenames gesetzt. So kann ich kann nach dem 1. Neustart sofort auf DNS-Namen zugreifen.

Ich frage mich, warum das Eisfair nicht auch macht. Das wäre u.a. eine Hilfe beim Testen mit unterschiedlichen Systemen.

Aber die Sache geht ja noch weiter. Jetzt wird's irgendwie kurios und für mich unverständlich:

Folgendes:
im Base-Setup (setup-1-1-1) steht in (Beispiel):

	IP_ETH_1_NAME='enx5254006f7c96'
	IP_ETH_1_IPADDR='192.16.0.140'   <=== feste IP-Adresse, aber außerhalb des o.g. dyn. IP-Adressbereichs (.100-.120)

Der DHCP-Client ist so konfiguriert:
-----------------------------------------------------------
START_DHCPC='yes'
DHCPC_DEVICE_NAME='enx5254006f7c96'   <-- s.o. IP_ETH_1_NAME
DHCPC_DEVICE_MACADDR='52:54:00:6f:7c:96'
DHCPC_USE_PEERDNS='yes'
DHCPC_SET_DEFAULT_ROUTE='yes'
DHCPC_HOSTNAME='e64dhcpct'
-----------------------------------------------------------

Damit bekomme ich eine IP-Adresse aus dem dyn.Adressbereich des DHCP-Servers. Btw. werden auch _beide_ DNS-Server eingetragen 
(.6 und .5 !). Die Adresse lautet 192.168.0.101. Ich kann einwandfrei über DNS-Namen auf Systeme im Internet zugreifen. "ip a" 
zeigt genau diese Adresse, s.u.

Jetzt installiere ich "apache2" und konfiguriere den Zugriff über Port 80 auf die Standard Document Root (/var/www.htdocs). In 
diese Document Root kopiere ich irgend eine Datei und versuche diese Datei via wget "herunterzuladen (also vom eigenen System)

Dabei zeigt sich folgendes:

------------------------------------------------------------------------------------------
eis 2.8.15 # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
     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
2: enx5254006f7c96: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
     link/ether 52:54:00:6f:7c:96 brd ff:ff:ff:ff:ff:ff
     inet 192.168.0.101/24 brd 192.168.0.255 scope global enx5254006f7c96  <========== gültige und funktionierende IP-Adresse
        valid_lft forever preferred_lft forever
     inet6 fe80::5054:ff:fe6f:7c96/64 scope link
        valid_lft forever preferred_lft forever
eis 2.8.15 #

eis 2.8.15 # wget http://`hostname`/apache2.conf .   <========= "wget"-Download
--2019-05-24 01:28:05--  http://eis/apache2.conf
Resolving eis (eis)... 192.168.0.140  <========================= das ist die IP-Adresse aus dem Base-Setup, s.o. !!
Connecting to eis (eis)|192.168.0.140|:80... failed: No route to host.
--2019-05-24 01:28:08--  http://./
Resolving . (.)... failed: Name or service not known.
in.wget: unable to resolve host address '.'
eis 2.8.15 #
------------------------------------------------------------------------------------------

Wieso löst der DNS-Server den `hostname` bei "wget" zu 192.168.0.140 auf und nicht zu .101
Ich bin der Meinung, dass die via DHCPC geladene IP-Adresse gewinnen sollte. Wieso verwendet wget die (feste) Adresse aus dem 
Base-Setup? (Und das über das gleiche Interface (enx5254006f7c96)?)
Zum Test habe ich auf der Eisfair-VM den ssh-Zugang aktiviert und konnte von einem anderen System in LAN  mit dem DNS-Namen der 
VM einen ssh-Connect auf die VM machen, also .101!
"dig <Eisfair-VM-DNS-Name>" (auf der VM) zeigt auch die .101 ip.

Das praktische Problem dahinter tauchte beim Nextcloud-Setup auf, wo ich wieder die PHP7-CLI und PHP7-WEB Fehlermeldungen bekam.
Jürgens Erklärung zu diesen Fehlermeldungen im Hinterkopf, dass die Gültigkeit der PHP7/Apache/Nextcloud-Konfiguration u.a. mit 
einem Test auf sich selbst, also dem Nextcloud-Server (mit einem "wget") gemacht würde,
habe ich die beiden IP-Adressen aus dem Base-Setup und aus dem DHCPC angeglichen, und siehe, die Nextcloud-Konfig lief einwandfrei.
(Man sollte daher beim Nextcloud-Config und bei Verwendung von DHCP-Adressen die Adressauflösung mit wget testen!)

Bitte keine Anmerkungen, dass die VM als NC_Server eine feste IP haben soll... Das geht an meiner Frage vorbei.

Das ist jetzt ziemlich lang geraten, aber vielleicht mag sich doch jemand damit beschäftigen. Danke!

Nix für ungut, Friede :) und Grüße. / Hilmar. :-)