expertenaustausch > comp.hardware.* > comp.hardware.misc

Rudolf Harras (03.12.2019, 22:46)
Michael Limburg schrieb:
> Rudolf Harras wrote:
> Wenn die Partitionierung 1:1 übernommen wird, bleibt der Rest selbstverständlich
> "leer", was auch sonst. Schließlich gehört die Größe der Partitionen ja auch zum
> Merkmal einer Partition.
> Man wird nicht umhin kommen, die Partition(en) nachträglich zu vergrößern, wenn
> man den größeren Plattenplatz nutzen will.


Der Plattenplatz ist ja egal, es ging nur darum, dass NT möglichst startet, aber
das ist eben bei gleicher Partitionsgröße leider nicht der Fall.
Kay Martinen (04.12.2019, 00:39)
Am 26.11.2019 um 08:00 schrieb Ralph Aichinger:
> Kay Martinen <kay> wrote:
> Konkretes Beispiel gerade: 2 Bereiche einer Firmengruppe teilen sich
> eine Leitung, und sollen gegeneinander abgeschottet werden. Außerdem
> gibt es eine Legacy-Firewall die für VPNs verwendet wird und weiterhin
> angeschlossen bleiben muß. Der neue Router bekommt
> 1xUpstream-Anschluß, 1xManagement-Interface, 1x+IPMI (out of Band-Konsole
> des Servers), 1xDMZ, 1xinternes Netz A, 1xinternes Netz B, 1xLegacy-Firewall.


Upstream und 2*LAN ist schon klar. Aber was ich nicht verstehe, den
Grund nicht sehe ist:

- Warum Management und IPMI getrennt? Getrennte Admins oder nur wg. des
eh Separaten IPMI-Ports?
- Warum legt man nicht die Legacy-FW in die DMZ? Oder hat die kein 2.
Interface an dem Internes hängt?

> 7 Anschlüsse, die man sicher teilweise eliminieren kann, aber beim Preis
> eines LAN-Ports einfach praktisch sind.


Okay. Du; oder jemand anderes; meinte mal neue Server kämen eh oft schon
mit mind. 4 Ports. Haben aber in der 1-2 HE Klasse selten mehr als 2-3
Slots für Karten. Meine haben alle nur 2 sind aber auch älter.

> Nein, gar nichts verkehrt. Aber u.U. will man auch bei einem Virtualisierungs-
> host die DMZ rausziehen, eventuell hat man mehr als eine (ich hab 2
> getrennte Bereiche gehabt), etc.


2 Firmen = 2 DMZ oder geht's da auch um so eine Legacy-FW/VPN-Sache?

Wenn man mehr als einen DMZ Host hat und nur eine VM dazu dann hat man
aber noch nicht zu ende Virtualisiert. Migration in Progress?

Was mir bei meinem Privaten Setup immer noch nicht schmeckt: Ich hab
zwei Router, den WAN-Seitigen vom Provider und einen Internen hinter dem
mein Hauptnetz liegt. Ich könnte also theoretisch das Segment dazwischen
als DMZ Betrachten. Auf dem Internen (Virtualisierten) Router könnte ich
nat. auch ein Interface als DMZ belegen und nutzen, müsste dann aber vom
WAN dadurch in ein 3. Segment routen.

Das erstere ist einfacher, das Zweite kommt mir nicht wirklich sicherer
vor. Denkfehler? Wobei auch hier Ein Mix aus VM und Echtem Blech denkbar
wäre. Den internen Router z.B. hätte ich gern wieder aus der VM raus.

Leider spielt die vorgesehene HW nicht mit OPN was ein BSD-Problem zu
sein scheint. pfsense dürfte ähnlich reagieren und ipfire ist nicht
flexibel genug für meine Wünsche.

Kay
Ralph Aichinger (04.12.2019, 08:51)
Kay Martinen <kay> wrote:
> - Warum Management und IPMI getrennt? Getrennte Admins oder nur wg. des
> eh Separaten IPMI-Ports?


Weil ich dem geteilten IPMI-Port im Server nicht traue ;)
Ich will nicht, daß sich das IPMI am DMZ-Port meldet oder sowas.

> - Warum legt man nicht die Legacy-FW in die DMZ? Oder hat die kein 2.
> Interface an dem Internes hängt?


Ja, wäre auch möglich, aber ich finde es praktischer das getrennt zu
haben, macht die Fehlersuche einfacher, finde ich.

> Okay. Du; oder jemand anderes; meinte mal neue Server kämen eh oft schon
> mit mind. 4 Ports. Haben aber in der 1-2 HE Klasse selten mehr als 2-3
> Slots für Karten. Meine haben alle nur 2 sind aber auch älter.


Ich hab auch noch keinen billigeren Server gehabt, der mehr als 2
Ports hat.

> 2 Firmen = 2 DMZ oder geht's da auch um so eine Legacy-FW/VPN-Sache?


Bei mir ersteres.

> Wenn man mehr als einen DMZ Host hat und nur eine VM dazu dann hat man
> aber noch nicht zu ende Virtualisiert. Migration in Progress?


Bei mir wird immer irgendwas migriert ;)

> mein Hauptnetz liegt. Ich könnte also theoretisch das Segment dazwischen
> als DMZ Betrachten. Auf dem Internen (Virtualisierten) Router könnte ich


Aus Security-Sicht sicher.

> nat. auch ein Interface als DMZ belegen und nutzen, müsste dann aber vom
> WAN dadurch in ein 3. Segment routen.
> Das erstere ist einfacher, das Zweite kommt mir nicht wirklich sicherer
> vor. Denkfehler? Wobei auch hier Ein Mix aus VM und Echtem Blech denkbar
> wäre. Den internen Router z.B. hätte ich gern wieder aus der VM raus.
> Leider spielt die vorgesehene HW nicht mit OPN was ein BSD-Problem zu
> sein scheint. pfsense dürfte ähnlich reagieren und ipfire ist nicht
> flexibel genug für meine Wünsche.


Ich sehe jetzt virtualisierte Router nicht so als Problem an, YMMV.
Bei ernsthafter Anwendung würde ich sie aber auf einem anderen Host
laufen lassen als kritische interne Systeme.

/ralph
Thomas Orgelmacher (07.12.2019, 14:30)
Am 02.12.19 um 21:47 schrieb Rudolf Harras:
> Windows NT ist wirklich recht genau, ich habe schon eine etwas größere Platte
> probiert. Die hat das System zwar genommen, aber NT hat sie mit einem Bluescreen
> verweigert.


Seufz. Du machst es einem nicht gerade einfach.

Was denn für ein Bluescreen? 0x7b?

Gruß, Thomas
Rudolf Harras (10.12.2019, 18:06)
Ich habe jetzt mal eine SCSI-Karte gefunden un din einen PC eingebaut, und sogar
64bit-Treiber für Windows 10 dafür installieren können.

Welche VMWare nehme ich denn da am Besten?
Rudolf Harras (11.12.2019, 17:39)
Immerhin, ich habe nun mit einem Proxmox den Windows NT Bluescreen reproduziert.
STOP 0x0000007B (0xF1413BE0, 0xC0000034, 0x00000000, 0x00000000)
Inaccessible_Boot_Device
Rudolf Harras (12.12.2019, 02:17)
Thomas Orgelmacher schrieb:
> Was denn für ein Bluescreen? 0x7b?


Ja:
STOP 0x0000007B (0xF1413BE0, 0xC0000034, 0x00000000, 0x00000000)
Inaccessible_Boot_Device
Thomas Orgelmacher (18.12.2019, 21:34)
Am 11.12.19 um 16:39 schrieb Rudolf Harras:
> Immerhin, ich habe nun mit einem Proxmox den Windows NT Bluescreen reproduziert.
> STOP 0x0000007B (0xF1413BE0, 0xC0000034, 0x00000000, 0x00000000)
> Inaccessible_Boot_Device


Will sagen, dass NT beim Wechsel vom Real- in Protected-Mode keinen Treiber mehr
für den Platten-Controller gefunden hat. Der muß noch im laufenden, alten System
installiert werden bevor virtuelisiert wird. NT macht kein PnP.

Und da Proxmox für SCSI einen 53C895A emuliert (und für IDE irgendein steinaltes
Intel-Dingens, welches ich gerade nicht finde; NT sollte einen Standard-IDE-
Treiber dafür haben) sollte das kein Problem sein.

Thomas
Kay Martinen (25.12.2019, 21:28)
Am 18.12.2019 um 20:34 schrieb Thomas Orgelmacher:
> Am 11.12.19 um 16:39 schrieb Rudolf Harras:
>> Immerhin, ich habe nun mit einem Proxmox den Windows NT Bluescreen
>> reproduziert.
>> STOP 0x0000007B (0xF1413BE0, 0xC0000034, 0x00000000, 0x00000000)
>> Inaccessible_Boot_Device

> Und da Proxmox für SCSI einen 53C895A emuliert


Default, ja. Und einen 83C810, einen Megaraid SAS 7808EM2, Virtio SCSI
und SCSI Single und vmware pvscsi.

> (und für IDE irgendein
> steinaltes Intel-Dingens, welches ich gerade nicht finde;


Siehe hier:

> # lspci
> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) ....


IMHO meldete eine VM den auch als 440BX. Ich vermute die sind nahezu
baugleich. Oder ich verwechselte das mit echtem Blech von dem ich auch
noch PIII Boards hab.

Kay
Marcel Mueller (29.12.2019, 13:06)
Am 18.12.19 um 20:34 schrieb Thomas Orgelmacher:
[..]
> Intel-Dingens, welches ich gerade nicht finde; NT sollte einen
> Standard-IDE-
> Treiber dafür haben) sollte das kein Problem sein.


Ja, der ATAPI-Treiber kann das. Der muss aber erst aktiviert werden. Das
geht notfalls auch nachträglich. Man muss nur mit Regedit auf die
(virtuelle) Platte zugreifen können. Dann im Registry Hive "config" im
aktuellen ControlSet unter Services/ATAPI das DWORD Start auf 0 ändern.

Aber deswegen startet der Bursche noch nicht unbedingt. SCSI und ATAPI
könnten ein inkompatibles LBA-Mapping verwenden. Ich glaube darauf
reagiert NT allergisch.
Ferner könnte die Plattennummer eine andere sein. Das ist aber einfach
zu beheben. Einfach in der boot.ini die Zahlen hinter multi(... anpassen.

Plan B:
boot.ini editieren und Eintrag mit scsi(0)... erstellen. Dann den
passenden Treiber einfach ins Wurzelverzeichnis kopieren und in
ntbootdd.sys umbenennen. Das klappt immer, selbst mit dem atapi.sys
Treinber, und man braucht nur einen Texteditor und kein Regedit.

Marcel

Ähnliche Themen