Posts by Alti

Bergwichtel ja, richtig. Für eine Gegensprechanlage reicht aber Mono .

hyle und Der_Imperator, wie ich schon gesagt habe, ich wäre nie auf die Idee gekommen.

Ich habe dann den Test noch etwas "weiter vorne" gemacht. Ich habe dann die Soundkarten und die Mikrofone am Windowsrechner getestet. Und nichts funktionierte. Durch das Rausziehen und Reinstecken der Klinke nahm der Windowsrechner das Knacken auf aber keine Sprache. Damit war zumindest klar, dass die Soundkarte mit dem Rechner funktioniert, aber es war frustrierend, dass kein (noch nicht mal das Headsetmikrofon) Mikrofon funktionierte. Bis mir einfiel, dass gestern ein Mikrofon angekommen ist, das ich vor Verzweiflung schon vor einer Woche bestellt habe...

Und es funktioniert mit dem Windowsrechner...
... mit dem arecord ...
... und schlussendlich auch mit DoorPi.

Einzig, ich habe noch ein recht großes Rauschen mit drin, aber ich will ja keine Konzertaufnahme machen, ich will nur wissen, was der auf der anderen Seite quatscht

Danke für den Hinweis, wäre ich nie darauf gekommen. Dacht, wie beim Kopfhörer, einstecken --- funktioniert.

Viele Grüße Heiko

Oh man, auf diese Idee wäre ich nie gekommen...

Ich bin zurzeit unterwegs und werde es erst am Wochenende Testen können.

Da ich bei beiden USB Soundkarten im ALSA Mixer nur die "Lautstärke" regeln konnte aber nicht nach R und L, gehe ich davon aus, dass beide USB Soundkarten reine Mono Karten für Aufnahmen sind.

Ich überlege gerade, ob ich nicht die USB Karten zerlege und die Mikrofone direkt an die Kontakte löte...

Die beiden Mediamarkt-Komponenten, die ich gekauf habe im nen Hardware-Defekt, bzw. eine speifische "Unverträglichkeit" auszuschließen.

Quote from hyle

Dann leg mal die Datei /etc/asound.conf mit dem selben Inhalt der .asoundrc (da ist übrigens ein Punkt davor!) an.

Die /etc/asound.conf ist quasi das systemweite Einstellung im Gegensatz zur .asoundrc Einstellung nur für den User gilt.

leider weiterhin Rauschen

Das ist die Ausgabe, wenn ich im DoorPi ALSA: Device eingebe. Er geht auf den Default...

Und hier wieder mit ALSA: USB PnP Audio Device in der DoorPi.ini

Ich habe an vielen Stellen aufgegeben, das zu verstehen und leider ist auch der Forum-Server on DoorPi down, so dass es schwer an Dokumentationen zu kommen.

Ich habe jetzt in der alsa.conf wieder

defaults.ctl.card 1
defaults.pcm.card 1
defaults.pcm.device 0

eingetragen und jetzt findet DoorPi auch die Soundkarte wieder.

und das ist der Teil meiner DoorPi.ini

[SIP-Phone]
firewallpolicy = PolicyNoFirewall
audio_codecs = PCMA,PCMU
call_timeout = 15
capture_device = ALSA: USB PnP Audio Device
dialtone = !BASEPATH!/media/ShortDialTone.wav
dialtone_renew_every_start = False
dialtone_volume = 35
echo_cancellation_enabled = False
identity = DoorPi
local_port = 5060
max_call_time = 120
mic_gain_db = 0
playback_device = ALSA: USB PnP Audio Device
record_while_dialing = False
records = !BASEPATH!/records/%Y-%m-%d_%H-%M-%S.wav
sipphonetyp = linphone

Wenn arecord funktionieren würde und die Gegensprechanlage nicht, würde ich hier suchen, aber auch ohne DoorPi scheint ALSA das Mikrofonsignal nicht zu bekommen bzw. zu verarbeiten...

Ich hatte gem. der Anleitung im alsa.conf die beiden card-Einträge von 0 auf 1 gesetzt.

Ok, jetzt haben wir auch parallel die asoundrc angelegt. Mit der Änderung der alsa.conf und ohne asoundrc lief der alsamixer auch ohne Parameter.

DoorPi findet wieder nur den Default...

und arecord liefert auch nur Rauschen

pi@raspberrypi:~ $ alsamixer
cannot open mixer: No such file or directory

mit alsamixer -c 1 gehts wieder.

arecord -l hatte ich sofort gecheckt , hier aber nochmal alle Ausgaben...

pi@raspberrypi:~ $ cat /proc/asound/cards
 1 [Device         ]: USB-Audio - USB PnP Audio Device
                      USB PnP Audio Device at usb-20980000.usb-1, full speed
pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: Device [USB PnP Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
pi@raspberrypi:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Device [USB PnP Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
pi@raspberrypi:~ $

ok, jetzt findet DoorPi die Soundkarte nicht mehr...

Vorher stand dort "found 2 possible sounddevices:" und auch "ALSA: USB PnP Audio Device"

Ich habe gerade nochmal nachgeschaut. Die Änderung der alsa.conf war Teil der Anpassungen für DoorPi

VoIP Video Türsprechanlage mit dem Raspberry und DoorPI

Mein wohl umfangreichstes Smarthome-Projekt neigt sich nach fast 2 Jahren "tüfteln" dem erfolgreichem Ende zu. Eine Video Türsprechanlage mit dem…

mytec-home.de

Quote from hyle

Nicht gut! Die alsa.conf sollte man besser nicht anfassen.

Ok... ...also alles wieder zurück ändern?

Das Buster ist Headless, also ohne Desktop.

sieht nicht so aus...
bei nano ~/.asoundrc liefert er "New File"

Ich habe den Eintrag dort von card 0 auf card 1 geändert.

pi@raspberrypi:/etc $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Device [USB PnP Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
pi@raspberrypi:/etc $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: Device [USB PnP Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
pi@raspberrypi:/etc $

Zum Vergleich auch aplay -l mitgeliefert...

btw. die Datei /etc/asound.conf existiert bei mir nicht. Da oft auf sie refereniert wird, kann das der Grund sein?

Hallo zusammen,

Ich habe einen Pi Zero 1.1 WH mit Buster Image laufen (Hintergrund ist das DoorPi auf dem Zero läuft). An dem Zero habe ich schon verschiedene USB Soundkarten angeschlossen und verschiedene Mikrofone.
- USB Soundcard 5.1 Virtual Surround Sound von CSL (Online)
- VIGO USB sound card von speedlink (Mediamarkt)
- Noname Headset (inkl. Mikrofon, hören geht...)
- Lavalier Microphone SMART von Hama (Mediamarkt)

Beim Befehl arecord kommt leider immer nur Rauschen in der Datei an.
arecord -D plughw:1,0 -t wav -d 10 test.wav

ALSA (bzw. alsamixer) läuft in der Version 1.1.8

Das Mikrofon ist physisch eingeschaltet und über den Alsamixer eingeschaltet und auf 80%.

Die USB Soundkarte ist als card 1 im alsa.conf angegeben.

Ursprünglich dachte ich, dass es an DoorPi läge, da das Log des linphone-Moduls immer "Too much data in channel 0, 38 ms in excess dropped" meldete. Bis ich dann auf die Idee kam es mit arecord zu testen (aplay funktioniert), ob es überhaupt funktioniert. Und wie gesagt, egal, ob ich ins Mikro rede oder nicht, nur Rauschen ohne Schwankungen.

Da ich bei meinen bisherigen Pi-Projekten nie Mikrofone brauchte, befürche ich, dass das Problem ein Layer-8-Problem ist .

Kann mir jemand sagen wo ich welche Einstellungen, Einträge oder Sonstiges falsch oder vergessen habe?

Vielen Dank

Heiko

So ich bin ein Stückchen weiter, habe aber 'ne Menge Blut und Wasser geschwitzt.

Nach einiger Recherche habe ich auf der Seite Troubleshooting BIND9_DLZ Back End einen guten Einstig gefunden, denn mit dem Befehl samba_upgradedns --dns-backend=BIND9_DLZ eine Rekonfigurierung des Backends starten. Mir ist nämlich aufgefallen, dass nicht nur der oben genannte Pfad /usr/local/samba/bind-dns/named.conf fehlte, sondern auch der DNS User. Zuerst habe ich den DNS des DC1 "rekonfiguriert" mit dem Ergebnis, dass ich erstmal nicht wusste, wie ich den named neustarte, bis mir nach langer Zeit einfiel, dass ich den ja damals selbst compiliert hatte und ich den mit systemctl restart bind9custom neustarten muss.

Bei der Gelegenheit ist mir aufgefallen, dass ich in der /usr/local/bind9/etc/named.conf.option unter options den forward auf den Fritz Router gemacht habe, blöderweise war das Forwarding im Fritz Router auf die beiden DNS Sever DC1 und DC2. Das habe ich dann wie folgt behoben.

    forwarders
    {
        172.30.16.6;   #DC2
        1.1.1.1;       #Cloudflare
    };

Erster Erfolg war, dass die nervigen Errormeldungen der Fritzbox weg waren.

Danach habe ich den DNS DC2 "rekonfiguriert" mit dem er mir die /var/lib/samba/bind-dns/named.conf Datei anlegte. Auch hier scheiterte der Versuch named neu zu starten:

admin@DC2:/etc/samba $ systemctl status named

× named.service - BIND Domain Name Server

Loaded: loaded (/lib/systemd/system/named.service; enabled; preset: enabled)

Active: failed (Result: exit-code) since Wed 2023-11-29 10:36:28 CET; 1min 4s ago

Docs: man:named(8)

Process: 493859 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE)

Main PID: 493859 (code=exited, status=1/FAILURE)

CPU: 98ms

Nov 29 10:36:28 DC2 systemd[1]: named.service: Scheduled restart job, restart counter is at 5.

Nov 29 10:36:28 DC2 systemd[1]: Stopped named.service - BIND Domain Name Server.

Nov 29 10:36:28 DC2 systemd[1]: named.service: Start request repeated too quickly.

Nov 29 10:36:28 DC2 systemd[1]: named.service: Failed with result 'exit-code'.

Nov 29 10:36:28 DC2 systemd[1]: Failed to start named.service - BIND Domain Name Server.

Ich hoffte mit einem Reboot Abhilfe zu schaffen. Nur... nach dem Reboot startete der Server nicht mehr. Kein Medienzugriff (grüne LED). Mehrfach... nix... (vermutlich war ich zu ungeduldig). Ich hab dann der Server aus dem Rack genommen und zum Fernseher "geschleppt", um zu sehen, ob und was er überhaupt macht. Beim Start war der Regenbogenbildschirm zu sehen. Dann war das Videosignal weg und der Fernsehe schaltete um. Bis ich die Fernbedienung gefunden habe und wieder auf den Eingang gewechselt hatte, hatte sich noch nichts getan. Dann aber schien der Pi wieder ordnungsgemäß hoch zu fahren, bis am Ende lauter Bind9 bzw. named Fehler kamen.

Im journalctl sah es so aus:

Nov 29 10:33:17 DC2 named[493641]: loading configuration from '/etc/bind/named.conf'
Nov 29 10:33:17 DC2 named[493641]: /etc/bind/named.conf:12: parsing failed: file not found
Nov 29 10:33:17 DC2 named[493641]: loading configuration: file not found
Nov 29 10:33:17 DC2 named[493641]: exiting (due to fatal error)

bis ich auf die Idee kam, dass ich in der /etc/bind/named.conf ein include "/usr/local/samba/bind-dns/named.conf"; (siehe ganz oben) stehen hatte, statt ein include "/var/lib/samba/bind-dns/named.conf";.

Nach der Änderung und einem Neustart beider Server laufen beide wieder. Auch die RSATools sind wieder (mit den bekannten Fehlermeldungen) verwendbar.

Nur folgende Sachen stören oder irritieren mich:

1. Folgende Meldung im journalctl im DC1: /usr/local/bind9/etc/named.conf.options:12: undefined ACL 'no'
2. Ebenfalls im journalctl des DC2:

Nov 29 14:04:53 DC2 samba[850]: [2023/11/29 14:04:53.697517,  0] ../../source4/dsdb/dns/dns_update.c:85(dnsupdate_nameupdate_done)
Nov 29 14:04:53 DC2 samba[850]:   dnsupdate_nameupdate_done: Failed DNS update with exit code 110
Nov 29 14:04:53 DC2 samba[850]: [2023/11/29 14:04:53.714988,  0] ../../source4/dsdb/dns/dns_update.c:108(dnsupdate_spnupdate_done)
Nov 29 14:04:53 DC2 samba[850]:   ../../source4/dsdb/dns/dns_update.c:108: Failed SPN update - with error code 110

3. und sehr irritierend: Ich habe 2 Stunden nach dem Neustart innerhalb von ca. 20 Minutenrund 7.000 Einträge im journalctl folgender Art auf dem DC2 gehabt (DC1 ist 172.30.16.5):

Nov 29 15:59:16 DC2 named[728]: timed out resolving 'dl.google.com/A/IN': 1.1.1.1#53
Nov 29 15:59:16 DC2 named[728]: timed out resolving 'dl.google.com/A/IN': 1.1.1.1#53
Nov 29 15:59:16 DC2 named[728]: timed out resolving 'android.googleapis.com/A/IN': 1.1.1.1#53
Nov 29 15:59:17 DC2 named[728]: timed out resolving 'android.googleapis.com/A/IN': 1.1.1.1#53
Nov 29 15:59:17 DC2 named[728]: timed out resolving 'dl.google.com/A/IN': 172.30.16.5#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:1::53#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:7fd::1#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2801:1b8:10::b#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:7fe::53#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:9f::42#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:2::c#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:503:ba3e::2:30#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:503:c27::2:30#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:2f::f#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:a8::e#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:dc3::35#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:2d::d#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:12::d0d#53
Nov 29 15:59:17 DC2 named[728]: timed out resolving 'dl.google.com/A/IN': 172.30.16.5#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:1::53#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:7fd::1#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2801:1b8:10::b#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:7fe::53#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:9f::42#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:2::c#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:503:ba3e::2:30#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:503:c27::2:30#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:2f::f#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:a8::e#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:dc3::35#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:2d::d#53
Nov 29 15:59:17 DC2 named[728]: network unreachable resolving 'dl.google.com/A/IN': 2001:500:12::d0d#53
Nov 29 15:59:17 DC2 named[728]: timed out resolving 'android.googleapis.com/A/IN': 172.30.16.5#53

Auf dem DC1 sah es dagegen so aus:

Nov 29 15:59:19 DC1 named[540]: success resolving 'dl.google.com/A' (in 'google.com'?) after reducing the advertised EDNS UDP packet size to 512 octets
Nov 29 15:59:19 DC1 named[540]: success resolving 'android.googleapis.com/A' (in 'googleapis.com'?) after reducing the advertised EDNS UDP packet size to 512 octets
Nov 29 15:59:40 DC1 named[540]: success resolving 'api.fitbit.com.cdn.cloudflare.net/A' (in 'cloudflare.net'?) after disabling EDNS
Nov 29 15:59:45 DC1 named[540]: success resolving 'pdns196.ultradns.co.uk/A' (in 'ultradns.co.uk'?) after disabling EDNS
Nov 29 15:59:45 DC1 named[540]: success resolving 'pdns196.ultradns.info/A' (in 'ultradns.info'?) after reducing the advertised EDNS UDP packet size to 512 octets
Nov 29 16:02:48 DC1 named[540]: success resolving 'us-east-1.amazonaws.com/NS' (in 'us-east-1.amazonaws.com'?) after reducing the advertised EDNS UDP packet size to 5
Nov 29 16:02:53 DC1 named[540]: success resolving 'elb.us-east-1.amazonaws.com/NS' (in 'elb.us-east-1.amazonaws.com'?) after reducing the advertised EDNS UDP packet s
Nov 29 16:06:39 DC1 named[540]: success resolving 'auc.avira.com/NS' (in 'auc.avira.com'?) after reducing the advertised EDNS UDP packet size to 512 octets
Nov 29 16:06:40 DC1 named[540]: success resolving 'muw1-ncs-spoc-prod-green.westus.cloudapp.azure.com/A' (in 'westus.cloudapp.azure.com'?) after disabling EDNS
Nov 29 16:06:43 DC1 named[540]: client @0x6f0b7913 172.30.16.104#51786: update 'zuhause.lokal/IN' denied
Nov 29 16:06:58 DC1 named[540]: success resolving 'azurewebsites.windows.net/NS' (in 'azurewebsites.windows.net'?) after reducing the advertised EDNS UDP packet size
Nov 29 16:07:03 DC1 named[540]: success resolving 'waws-prod-am2-339-lamb.westeurope.cloudapp.azure.com/A' (in 'westeurope.cloudapp.azure.com'?) after disabling EDNS
Nov 29 16:07:41 DC1 named[540]: success resolving 'albapigateway01-907695634.eu-central-1.elb.amazonaws.com/A' (in 'eu-central-1.elb.amazonaws.com'?) after disabling
Nov 29 16:07:46 DC1 named[540]: success resolving 'prod-vpn-api-20220523-190101.eu-central-1.elasticbeanstalk.com/A' (in 'eu-central-1.elasticbeanstalk.com'?) after r
Nov 29 16:07:46 DC1 named[540]: success resolving 'eu-central-1.elasticbeanstalk.com/NS' (in 'eu-central-1.elasticbeanstalk.com'?) after reducing the advertised EDNS
Nov 29 16:07:49 DC1 named[540]: success resolving 'detectportal.firefox.com/A' (in 'firefox.com'?) after reducing the advertised EDNS UDP packet size to 512 octets
Nov 29 16:07:49 DC1 named[540]: success resolving 'contile.services.mozilla.com/A' (in 'mozilla.com'?) after reducing the advertised EDNS UDP packet size to 512 octet
Nov 29 16:07:52 DC1 named[540]: success resolving 'proxyserverecs-1736642167.us-east-1.elb.amazonaws.com/A' (in 'us-east-1.elb.amazonaws.com'?) after reducing the adv
Nov 29 16:07:54 DC1 named[540]: success resolving 'detectportal.prod.mozaws.net/A' (in 'prod.mozaws.net'?) after reducing the advertised EDNS UDP packet size to 512 o
Nov 29 16:07:59 DC1 named[540]: success resolving 'services.mozaws.net/NS' (in 'services.mozaws.net'?) after reducing the advertised EDNS UDP packet size to 512 octet
Nov 29 16:08:05 DC1 named[540]: success resolving 'prod.cloudops.mozgcp.net/NS' (in 'prod.cloudops.mozgcp.net'?) after reducing the advertised EDNS UDP packet size to
Nov 29 16:08:05 DC1 named[540]: success resolving 'ns2.zdns.google/AAAA' (in 'zdns.google'?) after reducing the advertised EDNS UDP packet size to 512 octets
Nov 29 16:08:06 DC1 named[540]: success resolving 'ns1.zdns.google/AAAA' (in 'zdns.google'?) after reducing the advertised EDNS UDP packet size to 512 octets

Warum liefert der DC2 time outs und unreachable Meldungen überhaupt und in dieser Menge und der DC1 nicht.

4. und abschließend was ist das für eine Fehlermeldung:

Nov 29 16:06:43 DC1 named[540]: client @0x6f0b7913 172.30.16.104#51786: update 'zuhause.lokal/IN' denied

Ich hoffe jetzt sind meine Fragen etwas konkreter und ihr könnt mir helfen.

Viele Grüße

Heiko

Vielen Dank für die Rückmeldung.

Mir ist klar, dass ein heterogenes Netz immer etwas schwieriger ist.

Der Samba Server läuft auf einem Raspberry und in der Domäne gibt es keinen Windows Server. Aber genau aus dem von Dir genannte Grund hatte ich einiger Fehlermeldungen des RSAT unter der inkompartibilität des (Windows) RSATools mit dem Samba Server verbucht. Da viele der Fehlermeldungen offiziel auf einen "unsauberen" DNS hindeuten, was Dein Post bestetigt. Das sonst alles einwandfrei lief hatte ich mir dann auch keine weiteren Gedanken gemacht.

Aber als ich jetzt neben dem Linux Samba Server einen zweiten Linux Samba Server aufgesetzt habe und dort der DNS nicht das tat was er sollte, bin ich auf die Suche gegangen und habe festgestellt, dass da doch etwas krumm ist, es aber meine Kompetenz übersteigt.

RTFM , schade, dass Du nicht helfen kannst. Ich habe Deine Hinweise immer sehr geschätzt.

Hallo zusammen,

ich bräuchte Eure Hilfe beim Aufräumen meines DNS in meine Active Directory Domäne.

Basierend auf diesem Thread habe ich beim join des neuen DC festgestellt, dass der DNS doch nicht immer tut was er soll bzw. der Samba Server. Bis dato hat der DNS funktioniert. Im HowTo von Samba Configuring the BIND9_DLZ Module steht "During the domain provisioning, join, or classic upgrade, the /usr/local/samba/bind-dns/named.conf file has been created." Leider ist diese Datei und auch nicht der Pfad beim join des DCs zu Domäne generiert worden. Darauf hin habe ich mich in die Tiefen der Logs und Konfigurationsdateien begeben und irgendwann festgestellt, dass ich Eure Hilfe brauche. Denn ich habe verschiedene DNS-Dateien gefunden, die alle vom Oktober 2019 sind und auch inhaltlich nicht mit der Anzeige des RSATools übereinstimmen. Der erste DC ist eine Samba 4.9.1, der neue DC ein 4.17.12. Im RSAT sind beide DCs identisch. Darüber hinaus habe ich in dem journalctl einige Einträge gefunden, das man denken könnte, Bind wird mehrfach gestartet, bzw es werden andere Pfade verwendet als der oben erwartete.

Zur Historie:
Ich habe den Samba 4.9.1 Server als AD DC im Oktober 2019 aufgesetzt und damit die Domäne provisioniert. Seit der Zeit läuft die Domäne eigentlich störungsfrei. Ich habe damals ein HowTo verwendet, dass inzwischen nicht mehr verfügbar ist, zumindest habe ich es nicht mehr gefunden. Damit weiß ich leider nicht mehr alle Schritte die ich vollzogen habe. Ich weiß, dass es damals nicht einfach war und ich mehrere Anläufe gebraucht habe. Darüber hinaus musste ich damals Bind9 selber compilieren (daher auch das bind9custom), weil die Version aus der Repo nicht die notwendigen Komponenten hatte.

Hier schon mal die jounalctl Einträge:

admin@DC1:/usr/local/bind9/sbin $ sudo journalctl | egrep bind
Nov 21 17:52:02 DC1 systemd[1]: Starting LSB: Start and stop bind9...
Nov 21 17:52:04 DC1 named[540]: built with '--prefix' '/usr/local/bind9' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr/include/gssapi' '--with-libtool' '--with-dlopen=yes' '--with-gssapi=yes' '--enable-threads' '--enable-largefile'
Nov 21 17:52:04 DC1 named[540]: loading configuration from '/usr/local/bind9/etc/named.conf'
Nov 21 17:52:05 DC1 named[540]: reading built-in trust anchors from file '/usr/local/bind9/etc/bind.keys'
Nov 21 17:52:05 DC1 named[540]: /usr/local/bind9/etc/named.conf.options:11: undefined ACL 'no'
Nov 21 17:52:14 DC1 named[540]: set up managed keys zone for view _default, file 'managed-keys.bind'
Nov 21 17:52:14 DC1 named[540]: configuring command channel from '/usr/local/bind9/etc/rndc.key'
Nov 21 17:52:14 DC1 bind9custom[488]: Starting domain name service...: bind9.
Nov 21 17:52:14 DC1 systemd[1]: Started LSB: Start and stop bind9.
Nov 21 17:52:14 DC1 samba[617]: task[cldapd][617]:   Failed to bind to ipv6::::389 - NT_STATUS_INVALID_PARAMETER_MIX
Nov 21 17:52:14 DC1 samba[618]: task[kdc][618]:   Failed to bind to :::88 TCP - NT_STATUS_INVALID_PARAMETER_MIX
Nov 21 17:52:14 DC1 samba[618]: task[kdc][618]:   Failed to bind to :::464 TCP - NT_STATUS_INVALID_PARAMETER_MIX
Nov 21 17:52:15 DC1 samba[616]: task[ldapsrv][616]:   ldapsrv failed to bind to :::389 - NT_STATUS_INVALID_PARAMETER_MIX
Nov 21 17:52:16 DC1 winbindd[625]: [2023/11/21 17:52:16.784493,  0] ../source3/winbindd/winbindd_cache.c:3160(initialize_winbindd_cache)
Nov 21 17:52:16 DC1 winbindd[625]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
Nov 21 17:52:17 DC1 winbindd[625]: [2023/11/21 17:52:17.150684,  0] ../lib/util/become_daemon.c:138(daemon_ready)
Nov 21 17:52:17 DC1 winbindd[625]:   daemon_ready: STATUS=daemon 'winbindd' finished starting up and ready to serve connections

Was braucht ihr noch für Infos um einen Überblick zu bekommen?

Noch ein paar Hinweise:

Im Netz ist auch eine Fritzbox die immer wieder einen DNS error auslöstnamed[540]: DNS format error from xxx.xxx.xxx.xxx#53 resolving ./NS: unrelated SOA fritz.box in . authority section, was ich aber als unkritisches Grundrauschen wahrgenommen habe, da ich "fritz.box" nicht ändern kann. Wenn man das auch loswerden kann wäre auch toll.

Die DNS Einträge der Fritzbox verweisen auf DC1 und DC2.

Der DHCP läuft auf dem DC1 und nicht auf der Fritzbox.

Vielen Dank schon mal für Eure Unterstützung

Heiko

Hallo zusammen,

ich beantworte mal die Frage selber.

Ja, es geht und die Idee dahinter funktioniert. Aktuell laufen in meiner Domäne eine Samba 4.17.12 Server als AD DC auf Bookworm und ein 4.9.1 (Korrektur zum Ursprunspost) auf Buster und sind repliziert. Der Windows 11 (22H2) Rechner ist jetzt in der Domäne aufgenommen und ich kann mich mit dem Domänenbenutzer auf dem Windowsrechner anmelden.

Kleinen Specialeffect: Dadurch das beide DCs die Anfragen entgegennehmen können, war es am Anfang ein wenig Anmede-Roulette. Wenn der 4.9.1 die Anfrage entgegen nahm wurde sie logischerweise "abgelehnt" (wegen falscher Verschlüsselung), wenn der 4.17.12 sie entgegennahm, war alles super und die Anmeldung ging durch. Ich habe am Anfang immer wieder das Netzwerkkabel gezogen, um eine Neuverbindung zum Netzwerk zu provozieren.

Nach dem ich dem 4.17.12 Server die FSMO Rolle gegeben habe hat sich zumindest subjektiv das Anmeldeverhalten deutlich verbessert. Bisher hatten wir keine Rejects mehr. Kann natürlich auch daran liegen, dass der Domänenbenutzer jetzt auch lokal bekannt ist. Interessant wird die nächste Passwortänderung.

Leider habe ich bei der Aktion festgestellt, dass ich vor 4 Jahren wohl irgendwo beim DNS ein Bock geschossen habe, einige Teile musste ich damals noch selbst compilieren. Eigentlich läuft und lief die Domäne und die Server problemlos, bei der Aktion jetzt fällt aber auf, dass ein paar Reationen nicht konsisten sind. Aber dafür mache ich einen eigenen Thread auf.

Viele Grüße

Heiko

Hallo zusammen,

ich habe vor ca. 4 Jahren auf meinem Pi mit Buster einen Samba DC für eine AD Domäne aufgesetzt. Die ADD läuft seit 4 Jahren nun einwandfrei und ohne Störung. Unter der Prämisse, never change a running system, habe ich zwar die Updates gemacht, bin aber nie mit dem Server auf Bullseye oder Bookworm gewechselt. Dadurch blieb der Samba Server auch auf der Version 4.9.5 "stecken" (der FSMO sogar auf 4.9.1).

Da wir in der Familie aber auch ein paar Windowsrechner haben und seit neuestem ein neuer GamingPC mit Windows11 22h2 (Link zur Problembeschreibung) ins Netz soll, komme ich nicht umhin min. auf Samba 4.16.2 zu wechseln.

Ich hatte mich damals vor 4 Jahren intensiv in das Thema Samba AD DC reingefuchst und es war nicht ohne, habe aber nachdem alles lief, nicht mehr daran gerührt. Ich könnte jetzt nicht aus dem Stand einen DC mal eben aufsetzen.

Mein erster Ansatz war deshalb den Server bzw. das OS von Buster auf Bullseye zu heben und danach auf Bookworm, was wohl zwar geht, aber nie empfohlen wird.

Da ich noch einen weiteren Samba DC habe und sich die DCs in einer ADD untereinander synchronisieren, habe ich mir überlegt, ich installiere auf dem BDC Bookworm und Samba 4.17.12 aus dem Repository, richte Samba als DC ein und joine ihn zur Domäne, dann sollten sich die beiden DCs synchronisieren. Wenn alles läuft nehme ich mir dann den "alten" DC vor. So laufe ich nicht Gefahr mir meine AD Domäne zu zerschießen.

Die Frage ist nur, kann ich einen Samba 4.9.1 DC und einen Samba 4.17.12 DC in einer AD Domäne laufen lassen und synchronisieren die sich?

Viele Grüße

Heiko

Edit: Ja ich weiss, es gibt in der AD keinen BDC, ich nenne ihn nur so, weil er über SD Karte läuft und der "Primäre" über eine SSD.

Hallo zusammen,

Es hat jetzt einige Zeit gedauert, zum Einen bis ich das gestestet habe und dann nochmal bis ich mich aufraffen konnte es hier zu schreiben.

Also bei mir hat

das Downgrade von Pi4 auf Pi3B+ nicht geklappt.

Ich habe ein SD mit Raspberry Pi 4 Image in einen Pi3B+ gepackt.

Ergebnis: nichts hat sich gerührt. Nicht einmal blitzte die grüne LED.

Da alle meine Pis ohne Monitor laufen, kann ich auch nicht sagen ob er irgendwas gemeldet hätte, hätte er einen Monitor ;-).

Was ich auch noch nicht getestet habe ist, ob ich mir jetzt auch das Image für den Pi4 zerschossen habe...

Ich hatte das Ergebnis befürchtet, da sich sicherlich das OS beim initialen Start auf die Hardware einrichtet, die halt zwischen 3b+ und 4 doch unterschiedlich ist. Das sind aber nur Mutmaßungen, da bin ich nicht tief genug im Thema.