Dies ist eine weiterführende Anleitung zu meinem Grundgerüst, basierend auf dem nachfolgenden Artikel:
PXE&TFTP&DHCP Server einrichten
HTTP / FTP Downloads in der PXE-Umgebung ermöglichen
Melden Sie sich zuallererst auf Ihrer DS an und navigieren Sie anschließend ins Paketzentrum. Dort angekommen installieren Sie die Web Station, denn diese ist zwingend Voraussetzung für unser Vorhaben. In Firmenumgebungen gibt es eventuell bereits einen Webserver! In meinem Beispiel beziehe ich mich allerdings nur auf die Einrichtung unter Verwendung der DS.
Es gäbe auch die Möglichkeit einen externen Webserver als Downloadquelle zu nutzen. Die Geschwindigkeit wäre allerdings dann durch Ihren Internetanschluss begrenzt. Bei einer 100 Mbit/s Leitung wären das dann ungefähr 12,5 MB/s (Theoretisch). Das wäre also deutlich langsamer als das über einen internen Webserver abzuwickeln der im eigenen Intranet steht und mit 1 Gbit angebunden ist! Außerdem; Wer hat schon eine 100 Mbit/s Leitung beim ISP? Wir reden hier schließlich über Deutschland, wo ein nicht kleiner Teil gerade mal an der 10 Mbit/s Marke kratzt. Genug der Scherze. 🙂
Wenn Sie die Web Station installiert haben stellen Sie diese bitte wie auf den Bildern zu sehen ist ein:
Welche PHP Version Sie auswählen ist egal, da wir PHP ja nicht benutzen wollen, sondern lediglich einen Webserver mit Downloadmöglichkeit wollen.
Im Unterpunkt „Virtueller Host“ klicken sie auf „Erstellen“.
Wählen Sie dort portbasiert aus und aktivieren Sie daneben die HTTP Checkbox. HTTPS Verbindungen unterstützt Syslinux nicht! Diesen brauchen wir nicht. Vergeben Sie nun einen Port für Ihren Webserver. Im Standardfall ist Port 80 immer der normale HTTP Port. In unserem Fall ist es jedoch ratsam einen speziellen Port auszuwählen. Tragen Sie dort einfach 7777 oder einen Port Ihrer Wahl ein. Bedenken Sie dabei, dass Sie keine Ports verwenden dürfen, die durch andere Dienste in Ihrer Umgebung bereits genutzt werden. Der Dokument Root sollte der TFTP Root sein. Wie der bei Ihnen lautet müssen Sie selbst wissen.
Ich mache Ihnen trotzdem mal ein Beispiel (So könnten Sie Ihr TFTP Root in der DS genannt haben):
/PXEServer/TFTP/
/TFTPRoot/
In unserer Anleitung zum Einrichten des TFTP&PXE Servers hatten wir eine gewisse Verzeichnisstruktur angelegt. Suchen Sie einfach die Datei „pxelinux.0„. Alle Ordner die Sie dafür wechseln mussten sind der Pfad Ihres TFTP Root’s.
Beispiel:
/PXEServer/TFTP/pxelinux.0 => TFTP Root => /PXEServer/TFTP/
Als Nächstes wählen Sie noch bei HTTP-Backend „Nginx“ aus. Bei „PHP“ das Standard Profil.
Somit ist der Webserver auch soweit eingerichtet.
PXElinux Konfigurationsdateien editieren
Öffnen Sie die Datei: „pxelinux.cfg/default_BIOS“ in einem Editor. Ich mache Ihnen ein Beispiel wie Sie bereits vorhandene Einträge abändern könnten.
So sieht ein Eintrag bei mir in dieser Datei aus:
LABEL WinPE50X32ISO MENU LABEL 1. WinPE 10.0 Build 1709 x32 Bit - MemDisk ISO MENU INDENT 2 COM32 linux.c32 memdisk APPEND iso raw INITRD images/Winpe/WinPE10.0/WinPE_x86.iso TEXT HELP Es wird die Windows Vorinstallations Umgebung 10.0 im 32 Bit Modus geladen mit allen Netzwerktreibern. Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren. Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut. ENDTEXT
Sie sehen hier einen Eintrag um die 32-Bit WinPE 10 Version über Memdisk zu laden. Sie müssen nichts anderes machen, als vor dem Pfad der ISO Datei noch ein http://DS_IP_ADRESSE:PORT/ (Beispiel: http://192.168.1.5:7777/ ) davor zu stellen.
Nach dem Bearbeiten sollte der Eintrag so aussehen:
LABEL WinPE50X32ISO MENU LABEL 1. WinPE 10.0 Build 1709 x32 Bit - MemDisk ISO MENU INDENT 2 COM32 linux.c32 memdisk APPEND iso raw INITRD http://192.168.1.5:7777/images/Winpe/WinPE10.0/WinPE_x86.iso TEXT HELP Es wird die Windows Vorinstallations Umgebung 10.0 im 32 Bit Modus geladen mit allen Netzwerktreibern. Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren. Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut. ENDTEXT
Anpassen der iPXE Konfiguration
Suchen Sie nun folgende Dinge in der pxeEFI32.ipxe.cfg und pxeEFI64.ipxe.cfg:
set http-server SERVER_IP
Ersetzen Sie die SERVER_IP mit der HTTP Server IP Adresse.
Beispiel: 192.168.1.5:7777
Suchen Sie:
#set boot-url http://${http-server}/
set boot-url tftp://${next-server}/
und ersetzen Sie dies mit:
set boot-url http://${http-server}/
#set boot-url tftp://${next-server}/
Dadurch werden fast sämtliche Anfragen und Datenübertragungen über den HTTP Server gestellt und geleitet.
Das Booten über lpxelinux.0 einrichten
Aus unserer vorherigen Anleitung booten wir die pxelinux.0 Datei im Legacy Modus. Da diese Datei den HTTP / FTP Modus nicht unterstützt, werden wir noch ein wenig verändern müssen.
Laden Sie sich deswegen nochmal die aktuellste Syslinux Version herunter.
https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.04/syslinux-6.04-pre1.zip
Nach dem Entpacken kopieren Sie die Datei Syslinux 6.04\bios\core\lpxelinux.0 in das TFTP Root Verzeichnis Ihrer DS. Die Datei muss im selben Ordner liegen wie die Datei „pxelinux.0„!
DHCP Server (Dnsmasq) via SSH-Verbindung editieren
Melden Sie sich mit Putty über SSH auf Ihrer Synology an. Der zu verwendende Benutzername ist admin und nicht root. Sie können sich nämlich nicht direkt als root Nutzer einloggen! Über sudo -i könnten Sie dann nachher wechseln. Müssen Sie aber nicht!
Wenn Ihr eingeloggt seid, dann tippt folgendes ein:
cd /etc/dhcpd/
sudo vi dhcpd-pxe.conf
Sie werden nun erneut nach dem Passwort gefragt! Nach dem eingeben erscheint der Inhalt der Datei!
Die Datei kann verschieden aussehen, je nachdem welche Anleitungen Sie bereits durchgegangen sind. In dieser Datei ist immer pxelinux.0 durch lpxelinux.0 zu ersetzen! Insgesamt kommt pxelinux.0 zweimal in der ganzen Datei vor!
Kopieren Sie bitte nicht mein Beispiel, sondern ändern Sie das bitte von Hand ab!
log-dhcp # PXEClient Codes dhcp-vendorclass=x86-BIOS,PXEClient:Arch:00000 # BIOS/Legacy Modus dhcp-vendorclass=x86-UEFI32,PXEClient:Arch:00006 # x86 32-Bit EFI dhcp-vendorclass=x86-UEFI,PXEClient:Arch:00007 # x86_64 64-Bit EFI dhcp-vendorclass=x86-UEFI64,PXEClient:Arch:00009 # x86_64 64-Bit EFI veraltet! dhcp-vendorclass=ARM-UEFI32,PXEClient:Arch:00010 # ARM 32-Bit EFI dhcp-vendorclass=ARM-UEFI64,PXEClient:Arch:00011 # ARM 64-Bit EFI # In der Standardkonfiguration wird PXELinux für BIOS/Legacy Clients verteilt! # Für UEFI & UEFI64 Clients wird die iPXE Firmware verwendet! # Sie können auch alles über iPXE laufen lassen, müssen aber stets darauf achten, # dass immer nur ein Eintrag pro Modus aktiv ist! # Durch das setzen der Raute vor den Zeilen können Sie die Zeilen deaktivieren. # PXE Boot Abschnitt # Beispiel Eintrag und Erklärung # Boot-Tag, Boot-Dateiname, Server Name (DNS), Server IP Addresse # dhcp-boot=tag:x86-BIOS,pxelinux.0,0.0.0.0,0.0.0.0 # Boot-Tag, DHCP-Option 209, Pfad zur Syslinux-Konfigurationsdatei # dhcp-option-force=tag:x86-BIOS,209,pxelinux.cfg/default_BIOS # BIOS/Legacy Modus # PXELinux / Syslinux dhcp-boot=tag:x86-BIOS,pxelinux.0,0.0.0.0,0.0.0.0 dhcp-option-force=tag:x86-BIOS,209,pxelinux.cfg/default_BIOS # x86 32-Bit EFI Windows-Boot-Manager Eintrag # dhcp-boot=tag:x86-UEFI32,bootia32.efi,0.0.0.0,0.0.0.0 # x86_64 64-Bit EFI Windows-Boot-Manager Eintrag # Standard für die meisten UEFI Rechner # dhcp-boot=tag:x86-UEFI,bootx64.efi,0.0.0.0,0.0.0.0 # x86_64 64-Bit EFI Veraltet! Windows-Boot-Manager Eintrag # dhcp-boot=tag:x86-UEFI64,bootx64.efi,0.0.0.0,0.0.0.0 # iPXE Abschnitt # Alle aktivierten Einträge verwenden die iPXE Firmware dhcp-match=set:iPXE,175 # iPXE sends a 175 option. # Die erste Zeile ist stets die Firmware! # Die zweite Zeile ist der eigentliche Bootloader! # BIOS/Legacy Modus # dhcp-boot=tag:!iPXE,tag:x86-BIOS,undionly.kpxe,0.0.0.0,0.0.0.0 # dhcp-boot=tag:x86-BIOS,tag:iPXE,pxelinux.kpxe,0.0.0.0,0.0.0.0 # x86 32-Bit EFI dhcp-boot=tag:!iPXE,tag:x86-UEFI32,iPXE32.efi,0.0.0.0,0.0.0.0 dhcp-boot=tag:x86-UEFI32,tag:iPXE,pxeEFI32.ipxe,0.0.0.0,0.0.0.0 # x86_64 64-Bit EFI # Standard für die meisten UEFI Rechner dhcp-boot=tag:!iPXE,tag:x86-UEFI,iPXE64.efi,0.0.0.0,0.0.0.0 dhcp-boot=tag:x86-UEFI,tag:iPXE,pxeEFI64.ipxe,0.0.0.0,0.0.0.0 # x86_64 64-Bit EFI Veraltet! Manche VMs benötigen diesen Eintrag noch! dhcp-boot=tag:!iPXE,tag:x86-UEFI64,iPXE64.efi,0.0.0.0,0.0.0.0 dhcp-boot=tag:x86-UEFI64,tag:iPXE,pxeEFI64.ipxe,0.0.0.0,0.0.0.0 # Diese erforderlichen Dateien liegen meinem Paket nicht bei! # Diese müssen, wer diese benötigt, selbst erstellt/kompiliert werden! # ARM 32-Bit EFI # dhcp-boot=tag:!iPXE,tag:ARM-UEFI32,iPXE-ARM-32.efi,0.0.0.0,0.0.0.0 # dhcp-boot=tag:ARM-UEFI32,tag:iPXE,pxe-ARM-EFI32.ipxe,0.0.0.0,0.0.0.0 # ARM 64-Bit EFI # dhcp-boot=tag:!iPXE,tag:ARM-UEFI64,iPXE-ARM-64.efi,0.0.0.0,0.0.0.0 # dhcp-boot=tag:ARM-UEFI64,tag:iPXE,pxe-ARM-EFI64.ipxe,0.0.0.0,0.0.0.0
Wenn Sie die EINFÜGEN Taste einmal drücken, können Sie die Einträge verändern. Wenn Sie damit fertig sind drücken Sie einmal die ESC Taste.
Danach schreiben Sie folgendes:
:w und mit ENTER bestätigen. Die Meldung erscheint, dass der Inhalt gespeichert wurde!
:q und mit ENTER bestätigen. Sie verlassen den Editor!
DHCP Server neu starten
Damit unsere Änderungen auch angenommen werden, muss der DHCP Server einmal neu gestartet werden. Gehen Sie dafür im DSM auf Systemsteuerung und dann DHCP Server und klicken dort einmal auf DHCP deaktivieren und im Anschluss nochmals auf aktivieren.
Der Test
Starten Sie den Rechner über PXE im Legacy Modus und überprüfen Sie, ob der Eintrag ordnungsgemäß funktioniert! Die Geschwindigkeit sollte deutlich besser sein, als TFTP Transfers. Ich habe selber mal geprüft wie viel schneller das nun vonstatten geht und in meinem Fall ist es der Faktor X4-X15. Im TFTP Protokoll werden die Daten mit ca. ~5 MB/s übertragen ohne TFTPBlockSize Angaben! Mit optimierten Werten komme ich auf ca. 25-30 MB/s. Das sind ganz ordentliche Werte, aber trotzdem noch kein Vergleich zu den HTTP Downloads.
Über HTTP mit ungefähr 20-100 MB/s im eigenen Intranet (Natürlich ist das abhängig von der aktuellen Netzwerklast/Auslastung der Synology). Ich habe hier privat überall 1 Gbit verlegt. Theoretisch wären 125 MB/s möglich. Real ungefähr 115 MB/s.
Testen Sie es einfach selbst wie schnell es nun geht. Es ist jedenfalls eine deutlich spürbare Verbesserung.
Hallo Stefan,
in der default_BIOS werden ja nur die Pfade der iso-Dateien der MemDisk-Einträge mit „http://192.168.1.5:7777/“ editiert….
Wie verhält es sich mit den mit den Bootmanager-Einträgen (wim-Dateien)….müssen hier keine Pfade für den schneller HTTP-Modus angepasst werden? kann/soll man auch die default_EFI32 und default_EFI64 anpassen…hier gibt es ja nur Bootmanager-Einträge….
Ich kenne mich leider selbst nicht so gut mit der BCD Struktur aus. Ich hatte da zwar auch mal versucht einfach eine HTTP Adresse zu benutzen, aber das schlug fehl. Auch meine Suchbemühungen im Internet fanden nichts.
Ich habe aber noch eine Idee.
Kannst du mal bitte im UEFI Modus immer das WinPE x64 Image laden und die Zeit stoppen bis der Ladebalken verschwunden ist?
Eventuell kann man die Zeit ein wenig tunen. Ich habe das gerade selber bei mir ausprobiert. Bitte folgendes der CreateCustomBCD_WinPE_BIOS_AND_UEFI_X86_X64.cmd nach der Zeile:
bcdedit -store C:\BCD -set {ramdiskoptions} ramdisksdipath \Boot\boot.sdihinzufügen:
bcdedit -store C:\BCD -set {ramdiskoptions} ramdisktftpblocksize 4096 bcdedit -store C:\BCD -set {ramdiskoptions} ramdisktftpwindowsize 16 bcdedit -store C:\BCD -set {ramdiskoptions} ramdisktftpvarwindow YesDann lässt du die BCD-Datei erstellen, überschreibst die Alte im Boot\ Verzeichnis auf dem TFTP Server und nimmst erneut die Zeit. Dann änderst du beim zweiten Durchlauf die 4096 in 8192, speichern, BCD-Datei erstellen lassen, wieder überschreiben und erneut die Zeit messen.
Beim letzten Durchlauf den Wert auf 16384 setzen und das ganze nochmal.
Meine Benchmarkergebnisse:
Datei: WinPE_x64.wim = 296MB
Standard = 1 Minute 27,41 Sekunden = 3,3MB/s
Wert 4096 = 32,4 Sekunden = 9,13MB/s
Wert 8192 = 24,02 Sekunden = 12,32MB/s
Wert 16384 = 21,05 Sekunden = 14,06MB/s
Es lohnt sich also dies zu ändern. Probier es aus. Die Werte schwanken zwar prinzipiell ein wenig, aber dennoch sind diese im Schnitt deutlich besser als mit Standardeinstellungen. Das kommt zwar nicht an die Geschwindigkeit des HTTP Servers ran, aber trotzdem ist das zufriedenstellend.
Das Editieren der default_EFI32 und default_EFI64 Dateien kannst du Dir prinzipiell ab jetzt sparen. Du nutzt ja im UEFI Modus den Windows-Boot-Manager, also werden die gar nicht beachtet. Ich habe zwar noch die Hoffnung, dass in einer neueren Syslinux Version dann auch endlich mal irgendwann der UEFI Boot-Manager startbar ist, aber bis dahin müssen wir das halt solange ignorieren.
Hallo Stefan,
ich frage deswegen, weil die WIM-Dateien im Bootmanager bei mir extrem langsam laden.
Habe folgendes Fehlverhalten im BIOS-Legacy Modus:
Wenn ich in der Backup Section den obersten Acronis True Image Eintrag (memdisk – langsam) auswähle „flutscht“ innerhalb von 5 Sekunden die Oberfläche der Acronis-Rescue-Oberfläche auf den Bildschirm !!! Alles Wunderbar !!!
Wenn ich die darunterliegenden Einträge (kernel Load – schnell ) auswähle tut sich gar nix –> schwarzer Bildschirm – ganz links oben blinkt der Cursor!
Wenn ich in der Windows Section die memdisk-Einträge auswähle –> alles bestens Start.cmd öffnet sich nach einigen Sekunden …alles gut !!!
Wenn ich jedoch den BootMgr auswähle …lädt dieser…wenn ich dann aber eine WIM auswähle (z.B. WinPE win 10 x64 oder Acronis_x86x64) dann dauert es schon mal 1 Minute bis der Fortschrittsbalken der Boot.sdi rüberläuft…..bei dem Fortschrittsbalken der der eigentlich wim.-Datei tut sich erst mal gar nichts ….nach 10 Min sieht man erst den ersten Abschnitt des Fortschriritts ganz links ….dauert also ewig…
Ich hab jetzt deine Idee vom letzten Post noch nicht ausprobiert…mache ich später noch 🙂
Ja, das weiß ich noch, denn das sagtest du schon einmal.
Hast du das Problem denn auch, wenn du den PC direkt mit dem NAS verbindest ohne irgendwelche Zwischengeräte wie Switches/Hubs/Router zu verwenden? Ich kenne deine Netzwerkstruktur nicht, aber das wäre das Erste was ich testen würde.
Da das Problem ja scheinbar alle Clients in deinem Netz haben muss das entweder an dem TFTP Server selbst liegen oder an Bandbreitenbeschränkungen, die beim NAS eingestellt worden sind oder eventuell an einem Gerät in deinem Netzwerk, wo alle dran angeschlossen sind.
Probiere erst einmal die Anpassung aus, danach sehen wir weiter. 🙂
Es gibt tatsächlich einen zentralen Netzwerk-Switch über welchen unser Netzwerk aufgeteilt wird (da hängen fast alle Geräte dran):
ABER: Da am gleichen PC der MemDisk Boot innerhalb von wenigen Sekunden flutscht, der Bootmanager-Boot jedoch unendlich langsam abläuft würde ich jetzt mal nicht mehr mein Netzwerk oder irgendwelche Switches verantwortlich machen !!!
Wenn ich im UEFI Modus das WinPE x64 Image lade ….dann kommt zunächst ein Fortschrittsbalken für die Datei „Boot.sdi“…das dauert ca 1 Min. Danach folgt der leere Fortschrittsbalken für die WinPE x64.wim….der bleibt erst mal ca. gefühlte 10 Minuten leer…dann kommt links das erste weisse Stück….wenn man das hochrechnet, dann dauert es sicher 1,5 Stunden…
Ich kann das morgen gerne mal testen …. frage mich aber ob das Tuning wirklich der richtige Lösungsansatz ist. Bei dir lädt die WinPE standardmäßig in einer Minute und 27 Sek (mit oder ohne HTTP?)…beim mir 1,5 Stunden…
1 Minute 27 Sekunden sind die Standardwerte bei mir beim TFTP Transfer OHNE jegliche Änderungen. Mit den Änderungen brauchen ich für 300MB über TFTP 15-20 Sekunden (BIOS oder UEFI ist egal, UEFI scheint aber immer ein bisschen langsamer zu sein). Schwankt immer ein bisschen. Über HTTP geht das deutlich schneller. Da sind es vielleicht 5 Sekunden.
Ich würde das Switch nicht ausschließen. Bei Managed-Switches kann man einiges einstellen. Traffic priorisieren, Bandbreitenbeschränkungen für einzelne Dienste etc. Eine vorhandene Firewall kann jedenfalls als Grund ausgeschlossen werden, denn dann würdest du gar keine Verbindung hergestellt bekommen.
Daher schließe einfach einen Rechner direkt an die Kiste an. Du musst ja schon schauen, das du den Fehlerkreis eingrenzen kannst. Wenn du aber nichts änderst, fischst du die ganze Zeit im Trüben. Du kannst ja auch erst wirklich ausschließen, das nichts anderes bei Euch im Netzwerk schuld ist, wenn bei einer Direktverbindung immer noch die Probleme bestehen. Dann weißt du jedenfalls das der Fehler irgendwas mit der Synology zu tun haben muss und kein anderes Gerät im Netz schuld ist über diesen der Netzwerkverkehr geleitet wird.
Die Aussage das Memdisk ja funktioniert und TFTP ja nicht, hat nicht sonderlich viel zu bedeuten. Du lädst die Dateien ja nicht über TFTP, sondern über den Webserver. Das ist nicht der gleiche Datenverkehr. Das sind zwei völlig unterschiedliche Protokolle. Und wenn da jetzt irgendwie ein Gerät zwischen hängt, das TFTP Datenverkehr drosselt, ja dann hast du dein beschriebenes Problem.
Bei der Synology könntest du auch selbst mal schauen, ob du irgendwelche Einträge unter Netzwerk => Datenfluss-Steuerung eingetragen hast.
Ansonsten könnte man noch den Traffic mit Wireshark analysieren. Das ist aber eher etwas für Leute, die Ahnung davon haben. Habt Ihr keinen IT-Systemadmin bei Euch oder machst du das alles selbst? 😀
Ich bin der Systemadmin (also ich mache alles selbst!) 🙂
Also Memdisk wird über Webserver geladen – und der Bootmanager über TFTP ? Das war ja meine ursprüngliche Frage…ich dachte beides wird über Webserver geladen sobald man HTTP einrichtet.
Das heißt wenn ich ausschliesslich UEFI-Rechner im Netzwerk hätte dann würde mir das Einrichten von HTTP gar keinen Geschwindigkeitsvorteil bringen !?
Du meinst also den neuen UEFI-Rechner mit LAN-Kabel direkt an die Diskstation anschliessen ….und dan PXE-Boot versuchen….ist zwar etwas aufwendig….aber vielleicht kann ich dann den Fehler tatsächlich eingrenzen
Zitat
„Also Memdisk wird über Webserver geladen – und der Bootmanager über TFTP ?“
Nein, Memdisk und der Bootmgr wird über TFTP geladen. Das siehst du, wenn du dir mal die TFTP-Logs anguckst (/var/log/opentftp.log). Über HTTP wird auch nur geladen, wo du vor dem Pfad die HTTP Adresse schreibst. lpxelinux.0 bringt nur den HTTP Support mit. Das Dateien via HTTP geladen werden sollen musst du aber explizit in den Dateien konfigurieren. Also die HTTP Adresse davor setzen. Andernfalls läuft das über das TFTP-Protokoll.
Zitat
„Das heißt wenn ich ausschliesslich UEFI-Rechner im Netzwerk hätte dann würde mir das Einrichten von HTTP gar keinen Geschwindigkeitsvorteil bringen !?“
ACK. Insofern es keine Möglichkeit in der BCD gibt so etwas anzugeben, nicht. Ich habe jedenfalls nichts dazu gefunden und auch die Microsoft Dokumentationen erwähnen diesbezüglich nichts. Es gibt nur den Support von Multicast-Verteilungen, was aber auch meines Wissens nach auch wieder über TFTP abläuft. Ich will mich hier aber auch nicht zu weit aus dem Fenster lehnen, denn vielleicht ist das doch möglich, nur ich habe es noch nicht entdeckt. Ich bin ja schließlich auch kein BCD-Profi 😀
Du wirst also das Problem lösen müssen. Ich kenne auch ansonsten nur sehr wenige Möglichkeiten das alles so nachzubauen wie ich mit den Anleitungen bereits getan habe. Entweder man hat sowieso einen Windows Server irgendwo stehen mit der WDS Rolle oder man baut sich das Konstrukt halt selbst.
Zitat
„Du meinst also den neuen UEFI-Rechner mit LAN-Kabel direkt an die Diskstation anschliessen ….und dan PXE-Boot versuchen….ist zwar etwas aufwendig….aber vielleicht kann ich dann den Fehler tatsächlich eingrenzen“
Wie gedenkst du denn sonst das Problem einzugrenzen, wenn nicht so? Du kannst das zwar machen wie du möchtest und du musst es auch nicht machen, wenn du nicht willst, aber irgendwo musst du ja anfangen. 🙂
Problem ist eingegrenzt: Hab die DS direkt mit den PC verbunden….hier funktioniert alles einwandfrei !!! Du hattest somit recht …es muss an dem Lancom Switch liegen, an dem sämtliche Geräte hängen.
Jetzt werde ich mich wohl mit dem Teil mal beschäftigen müssen (hier gibts zig Einstellungsmöglichkeiten) …denn hier wird wahrscheinlich der Datentransfer langsam ….
Übrigens kurz eine Anmerkung:
Du solltest in der Anleitung“ Lightweight IP…“ ergänzen, dass man auf der DS in der Systemsteuerung unter DHCP-Server den Bootloader auf „lpxelinux.0“ umstellen muss. Ist zwar logisch …sollte aber erwähnt werden in der Anleitung.
Danke für deine Hilfe !!
Zitat
„Du solltest in der Anleitung” Lightweight IP…” ergänzen, dass man auf der DS in der Systemsteuerung unter DHCP-Server den Bootloader auf “lpxelinux.0” umstellen muss. Ist zwar logisch …sollte aber erwähnt werden in der Anleitung. “
Ob du mir jetzt glaubst oder nicht, aber das ist pure Absicht! 😀 Denn, dadurch das wir im Nachhinein eh immer die dhcpd-pxe.conf bearbeiten, wird dem Eintrag keine Bedeutung mehr zugewiesen. Das war bei Dir damals nur notwendig, weil du das eben nicht nach meiner Anleitung eingerichtet hattest, sondern davon abgewichen warst. Da war das in der Tat erforderlich. Jetzt wäre das sowieso nur Makulatur, da der Eintrag schon lange nicht mehr beachtet wird.
Freut mich, dass du deiner Problemlösung einen Schritt näher gekommen bist. Für mich hört sich das alles so an, als hättest du das System der Firma übernommen, es aber nicht eingerichtet, richtig? Gibt es bei Euch keine Dokumentationen wo alles vermerkt wurde? Sich in einer Firma zurecht zu finden ohne jegliche Informationen zu dem IST-Status zu haben, ist schon hart. Du wirst das schon hinkriegen 🙂
Hallo erstmal
@Stefan Danke für deine Arbeit.. hat mir ein großes Stück weitergeholfen auf meiner Syno ein Ultimatives BootSystem einzurichten..
Allerdings hänge ich jetzt bei der HTTP Erweiterung..
vorweg:
meinen PC habe ich auf Bios Boot (MBR) eingestellt, wegen Bootmanager im MBR (2 Partitionen mit Win10)
mein PXE Server funktioniert grundsätzlich.. nur nicht über HTTP
meine config Zeilen lauten:
LABEL WinPE50X32ISO
MENU LABEL 2. WinPE 10.0 Build 1709 x32 Bit – per HTTP
MENU INDENT 2
COM32 linux.c32 memdisk
APPEND iso raw
INITRD http://192.168.2.20:7777/images/win10_pe/WinPE_10x86.iso
TEXT HELP
Es wird die Windows Vorinstallations Umgebung 10.0 im
32 Bit Modus geladen mit allen Netzwerktreibern.
Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich
mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren.
Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut.
ENDTEXT
LABEL WinPE50X32ISO
MENU LABEL 3. WinPE 10.0 Build 1709 x32 Bit – per ISO
MENU INDENT 2
COM32 linux.c32 memdisk
APPEND iso raw
INITRD images/win10_pe/WinPE_10x86.iso
TEXT HELP
Es wird die Windows Vorinstallations Umgebung 10.0 im
32 Bit Modus geladen mit allen Netzwerktreibern.
Die WinPE Versionen sind abwaertskompatibel. Es ist Ihnen moeglich
mit der WinPE 10.0 Version auch aeltere Windows Versionen zu installieren.
Es wird automatisch das Netzwerkshare zu den Windows Images aufgebaut.
ENDTEXT
Der Teil wo ich die ISO einfach nur mit initrd lade, funktionierts
Im Teil über HTTP funktionierts nicht und erhalte die Fehlermeldung, daß man die ISO nicht finden könne..
wenn ich die in der config-Zeile angegebene Adresse im Browser eingebe, werde ich gleich gefragt, was ich mit der ISO machen möchte, also downloadbar..
kann mir jemand helfen, wo ich her den Fehler habe..
Ich denke irgendwo einen Syntax oder Denkfehler..
mein HTTP-Root (und TFTP-ROOT) ist auf das Verzeichnis pxe gelegt, wo die pxelinux.0 liegt..
darunter gibt’s dann das /Images Verzeichnis und darunter dann z.B. das (/Images)/win10_pe Verzeichnis wo das ISO
drin liegt…
Danke für eure Hilfe
Das hört sich alles danach an, dass der falsche Bootloader verwendet wird.
Der pxelinux.0 (Syslinux-Bootloader ohne HTTP-Support) kann keine HTTP Adressen öffnen!
Der lpxelinux.0 (Syslinux-Bootloader mit HTTP-Support) dagegen schon.
Es scheint, als hättest du vergessen die dhcpd-pxe.conf zu bearbeiten und das pxelinux.0 durch lpxelinux.0 zu ersetzen.
Hat sich erledigt !!!….
Habe vergessen den HTTP Server neu zu starten….
und gleich funktionierts……
Hallo Stefan,
folgendes Phänomen tritt auf, wenn man den User Admin in der Diskstation standardmäßig nach dem Bearbeiten der dhcpd-pex.conf wieder deaktiviert. (Ist ja auch eine nachvollziehbare Sicherheitsmaßnahme.)
Wenn man die Datei editieren will muss man den User Admin wieder aktivieren. Soweit logisch.
Allerdings ist die Datei dann leer…
Auch die ebenfalls von mir angelegte Backupdatei dhcpd-pex.conf_ im gleichen Verzeichnis ist leer….
Das ist irgenwie unlogisch.
Überschreibt die Diskstation die Einträge beim erneuten aktiviern des Admins?
VG Matze
Habe ich nie getestet. Keine Ahnung. Je nachdem welche Pakete man installiert ist ein Deaktivieren des System Admins sowieso nicht mehr möglich. Das ist bei mir nämlich der Fall. Ich wäre aber auch nicht auf die Idee gekommen, diesen deaktivieren zu wollen. Es reicht meiner Meinung nach ein sehr starkes Passwort zu verwenden und die IPs der erfolglosen Anmeldeversuche automatisch bannen zu lassen. Außerdem kann man das in der Firewall soweit beschränken, dass man die Gefahr weitestgehend minimieren kann. Ob es jetzt sinnvoll ist die DS direkt über das Internet erreichbar zu machen ist eine ganz andere Geschichte. Normalerweise wäre da eine VPN Verbindung die bessere Wahl. Weil die DS dann nicht direkt im Internet hängen würde.
Wenn du in der Konsole den Befehl: ll in dem /etc/dhcpd/ Ordner eingibst wird dir auch die Dateigröße der Dateien mit 0 angezeigt?
Es ist ja nicht so, dass ich keinen Admin habe. Nur eben nicht den Standard-Admin.
Und mein Admin wird nicht deaktiviert. Ich deaktiviere nur den Standard-Admin, weil der logischerweise der erste ist, der angegeriffen wird. VPN ist richtig und du hast Recht, wenn man die IP-Beschränkung aktiviert, ist schon viel geholfen.
Habs grad noch mal mit ll getestet… und den Fehler gefunden… Ich hatte einen Buchstabendreher drin…. dhcpd-pex.conf statt dhcpd-pxe.conf gespeichert… damit war die Datei weg und er hat sie leer wieder hergestellt.
Es ist wie immer … Das Problem sitzt vor dem Bildschrim 😉
VG
Hi Stefan,
also das Phänomen tritt wieder auf. Die Diskstation setzt die dhcpd-pxe.conf zurück, sobald man PXE deaktiviert und bei Bedarf wieder aktiviert.
Ich muss es testen, ob es erhalten bleibt, wenn ich es einfach aktiviert lasse. Da meckert zwar der Sicherheitsberater der Diskstation, dass TFTP aktiv ist und ein Sicherheitsrisiko darstellt, aber in dem Verzeichnis kann ja Guest nur lesen. Sollte eingentlich kein Risiko sein…
VG Matze
Das die Datei beim Aktivieren oder Deaktivieren überschrieben/neu angelegt wird ist normal. Ebenso werden auch andere Dateien ständig neu angelegt oder überschrieben, wenn man die Diskstation neu startet (die dhcpd-pxe.conf bleibt auch nach dem Neustart erhalten). Normalerweise aktiviert und deaktiviert man diese Sachen ja auch nicht ständig…
Manche Meldungen kann man getrost ignorieren. Beim Nur-Lesen-Zugriff kann da nichts passieren.
Ja, du hast Recht… man muss es ja auch nicht ständig an und aus machen 😉
Ich lasse es jetzt an….
Der Sicherheitsberater schreibt:
Schwere: mittel
Beschreibung: TFTP-Dienst ist aktiviert
Details: Aufgrund der nicht verschlüsselten Verbindung sollten Sie zum Übertragen von Daten über das Internet TFTP nicht verwenden.
Empfohlene Aktion: Deaktiviern Sie in den TFTP Eintsellungen den TFTP-Dienst.
Insofern man den TFTP Server nicht von außen verfügbar macht, ist die Meldung sowieso hinfällig. 😀
Passe einfach deine Firewallregel an und erlaube nur das private Subnetz. Dann dürfte der auch nicht mehr meckern.