Beiträge von Alpha

Zitat von mrshadowtux

./make? Nur make, denn make liegt im PATH, nicht im Source-Directory

;D

Krasser Befehl?????

Zuerst solltest du entsprechend dir die PHP 4.4.9 Sourcen ziehen und kompilieren (./configure, ./make, ./make install).
Oder schauen, ob es ein Backport dafür gibt

PN ist raus

Zitat von mrshadowtux

Super, danke! Jetzt brauch ich nur noch was für Telegram

Geht leider noch nicht
https://github.com/telegramdesktop/tdesktop/issues/91

Die Tage gibts dann eine PN

Ihr kriegt die CDs, wenn Ihr PHP4 für michael_ einrichtet

Ich sollte die Tage die Recovery und Tools CDs fürn 100CT kriegen

Zitat von Benjamin92

Windows 2008 R2 ist sicher 64 bit.

Danke, stimmt, muss 64-Bit sein.

Um dann mal was konstruktives abzugeben. 64-Bit zu Zeiten von PHP4 war eher nicht weit verbreitet. Das PHP Binary ist also 32-Bit. Ein 64-Bit IIS ist damit schlicht inkompatibel. Das gilt auch für heutige Systeme. 64-Bit Webserver sind nicht mit 32-Bit Module kompatibel und anderrum.

Entweder ein 32-Bit Server OS (Wobei 2008 R2 es wohl nicht als 32-Bit gibt?) oder du musst versuchen, ob ein erneutes Kompilieren für 64-Bit klappt. Meine Prognose: Es wird nicht 1:1 klappen. Man wird den Code umschreiben müssen, damit es sauber mit 64-Bit kompiliert. Dazu sehe ich das Problem, dass ggf. aufgrund des Alters die genutzte API mit dem IIS vom 2008 R2 nicht kompatibel ist und somit ebenfalls neu geschrieben / angepasst werden müsste.

Jedenfalls kenne ich solche Spielchen mit PHP5 und IIS von meiner administrativen Zeit mit Windows Server..

Und mal ehrlich, niemand würde eine solche Arbeit für ein stark Veraltetes Modul für 50 Euro durchführen. Das ist einfach utopisch, weil das keine Arbeit ist, welche in 30 Minuten fertig ist.. 500 Euro klingt da wirklich mehr realistisch..

Hast du eigentlich ein 64-Bit oder 32-Bit Windows?

Zitat von DosAmp

Aber in dem Falle wohl die einzige Lösung, wenn man sowohl Linux als auch Windows mit Secure Boot parallel booten möchte?

Warum?
UEFI ist dein Boot Manager. Dort hinterlegst du den "Windows Boot Manager" (bzw. macht das Windows-Setup) und deinen "Linux Kernel" (mittels efibootmgr) als Booteinträge, welche gestartet werden.
So handhabe ich es hier. Mit F12 kann ich beim Starten vom PC mein Bootmenu vom UEFI aufrufen und Linux alternativ starten, da Windows als erstes eingetragen ist.

GRUB ist absolut nicht notwendig, bzw. braucht man im Prinzip mit UEFI überhaupt nicht mehr..

[EDIT]
Ubuntu ist ein Sonderfall. Deren siginierter GRUB2 ist gepatched! Wenn der GRUB2 keinen signierten Kernel von Canonical bekommt, kann er nichts booten! Damit wird Secure Boot sogesehen nicht ausgebelt.. Das könnte man sicher patchen, dass eigene Schlüssel siginiert werden.

Zitat von gandro

On-Topic: Wie machst du das mit der Initramdisk?

Wie genau meinst du das? Ich habe eine initramfs im Einsatz, weil LUKS. Gibt zwei Optionen. Entweder direkt in den Kernel miteinkompilieren oder im UEFI mitübergeben. Ich mache ersteres.. zweiteres sollte aber kein Problem sein. Mit efibootmgr einfach diese angeben:

efibootmgr --create --disk sda --part 1 --label "Gentoo Linux" --loader '\efi\gentoo\boot\kernel.efi' -u initrd='\efi\gentoo\boot\initramfs.img'

Oder worauf willst du hinaus?

Zitat von gandro

Off-Topic: Ich finde, Microsoft verdient hier eher Lob. Es ist Microsoft zu verdanken, dass man auf ausnahmsweise jedem UEFI die Microsoft-Schlüssel löschen und eigene einbauen kann. Damit man Geräte mit Windows-Aufkleber verkaufen darf, muss man dem User erlauben, seine eigenen Secureboot-Zertifikate zu installieren.

Jede Wette, dass wenn Microsoft diese Klausel nicht hätte, dass viele Hersteller solche Funktionen selber gar nicht einbauen würden. Und würde Microsoft Secureboot nicht erzwingen, glaube ich hätten wir das auch nicht.

Kurzum: Würde Microsoft die Secureboot-Regeln den Herstellern überlassen, wäre die Situation vermutlich noch viel schlimmer.

Leider (nicht mehr) so ganz richtig Bis Windows 8.1 stand das genauso drin, wie du es schreibst. Mit Windows 10 ist es nur noch optional seitens Microsoft und damit ist man vom Hersteller abhängig..

Zitat von mrshadowtux

Zum Glück kann man das noch im BIOS abschalten, die Frage ist halt wie lange noch. Wenn es die Abschaltoption in Zukunft nicht mehr gibt, kann dieses Tutorial durchaus nützlich sein.

Entscheidend ist, ob man Secure Boot in den Setup-Mode kriegt. Wenn das nicht geht und Secure Boot nicht abschaltbar ist, hat man verloren.
Worst Case Szenario wäre sonst, dass man sich den signierten GRUB von Ubuntu klaut, der ist mit einem Microsoft Key signiert.. aber das ist ziemlich unschön, finde ich..

Sofern es jemanden interessiert, hier ein kleines Howto, um Secure Boot einzurichten.
Ich gehe davon aus, dass euer System bereits mit UEFI lauffähig ist.

Vorbereitungen
Ihr müsst die efitools und efibootmgr installieren.
Im Regelfall sollte eure Distribution diese mitbringen oder als Paket anbieten.

Sicherung
Im ersten Schritt sollten die aktuellen Keys gesichert werden.

mkdir -p /etc/efi
chmod 700 /etc/efi
efi-readvar -v PK -o /etc/efi/old_PK.esl
efi-readvar -v KEK -o /etc/efi/old_KEK.esl
efi-readvar -v db -o /etc/efi/old_db.esl
efi-readvar -v dbx -o /etc/efi/old_dbx.esl
chmod 400 /etc/efi/*.key

Eigene Schlüssel erzeugen
Im nächsten Schritt erzeugen wir unsere eigenen Schlüssel. Der Text innerhalb subj für CN kann frei angepasst werden.

openssl req -new -x509 -newkey rsa:4096 -subj "/CN=My New Platform Key/" -keyout /etc/efi/PK.key -out /etc/efi/PK.crt -days 3650 -nodes -sha512
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=My New Key-Exchange-Key/" -keyout /etc/efi/KEK.key -out /etc/efi/KEK.crt -days 3650 -nodes -sha512
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=My New Kernel-Signing Key/" -keyout /etc/efi/db.key -out /etc/efi/db.crt -days 3650 -nodes -sha512

Secure Boot Schlüssel löschen
Jetzt müsst ihr den Rechner neustarten und im UEFI-Setup die Einstellungen für Secure Boot aufrufen.
Dort sollte es eine Option geben, mit welcher die vorhandenen Schlüssel gelöscht werden.
Bei mir hieß die Option Clear Secure Boot Keys, Secure Boot ist dannach automatisch deaktiviert und sollte sich im Setup-Mode befinden.

Eigene Secure Boot Schlüssel importieren
Startet wieder euere Linux-Distribution und beginnt mit dem Import der alten Schlüssel.

efi-updatevar -e -f /etc/efi/old_KEK.esl KEK
efi-updatevar -e -f /etc/efi/old_db.esl db
efi-updatevar -e -f /etc/efi/old_dbx.esl dbx

Danach kommen die eigenen Schlüssel:

cert-to-efi-sig-list -g "$(uuidgen)" /etc/efi/PK.crt /etc/efi/PK.esl
sign-efi-sig-list -k /etc/efi/PK.key -c /etc/efi/PK.crt PK /etc/efi/PK.esl /etc/efi/PK.auth
efi-updatevar -a -c /etc/efi/KEK.crt KEK
efi-updatevar -a -c /etc/efi/db.crt db
efi-updatevar -f /etc/efi/PK.auth PK

Wenn Ihr efi-readvar ohne weitere Argumente aufruft, solltet Ihr eine Auflistung aller Schlüssel bekommen. Dort muss jetzt auch der neue Schlüssel sichtbar sein.
Nach dem Einspielen der Schlüssel ist Secure Boot wieder im User-Modus und automatisch aktiv!

Kernel signieren
Im letzten Schritt wird jetzt der Kernel mit eurem Schlüssel signiert, damit dieser bei aktivierten Secure Boot validiert werden kann.
sbsign --key /etc/efi/db.key --cert /etc/efi/db.crt --output /Pfad/zum/signierten/bzImage.signed /Pfad/zum/aktuellen/nicht/siginierten/bzImage

Prüft mit efibootmgr -v, wo aktuell eurer Kernel-Eintrag liegt (Die *.efi-Datei). Die *.efi-Datei wird durch das neue bzImage.signed ersetzt.
Nach einem Reboot sollte mit aktivierten Secure Boot der Kernel starten.

Backup
Es wäre ratsam, wenn Ihr nach dem erfolgreichen Test ein Dump der neuen Schlüssel zieht, sollte im Falle eines Bios-Updates oder Mainboard-Schadens das Wiederherstellen dieser Schlüssel nötig sein.

efi-readvar -v PK -o /etc/efi/new_PK.esl
efi-readvar -v KEK -o /etc/efi/new_KEK.esl
efi-readvar -v db -o /etc/efi/new_db.esl
efi-readvar -v dbx -o /etc/efi/new_dbx.esl

Wie ich schon geschrieben habe, wird man nicht drum herum kommen, dass man PHP4 neu kompilieren muss. Ich tippe aber stark, dass das reine Kompilieren nicht reichen wird, weil man auch den Quellcode anpassen werden muss, damit es mit aktuellen System lauffähig ist.

Du kannst nicht erwarten, dass wir dir jetzt hier für dich den Quellcode modifizieren und alles anpassen. Das ist deine Aufgabe.

Zitat von Michael_

Wenn der Domain anbieter aber keine Nameserver hat wie es bei einigen wenigen speziellen endungen der fall ist wenn man sie direkt bei der vergabestelle registriert sondern also lediglich 2 felder für nameserver da sind?

Also ich weiß grad garnicht ob ich da diese möglichkeiten habe, ich habe schonmal ne domain von united domains gehabt da ging sowas natürlich alles

In Prinzip müsstest du dann dort die IP von deinem Server angeben, welche dann beim Registrar als zuständiger Server eingetragen wird. Je nach Stelle ist aber ein DNS-Server nicht erlaubt und es müssen mehrere sein.

Aber nun ja.. mach was du willst. DNS betreiben, freue mich schon, wenn dein Server missbraucht wird..

Jetzt sag nicht, der DNS ist nach außen erreichbar o_O

Zitat von mrshadowtux

Bitte kein FTP mehr verwenden, das überträgt Passwörter im Klartext und hat damit das "Sicherhetisniveau" von Telnet!

Implementier lieber SFTP, das verschlüsselt dann auch sicher per SSH. Läßt sich auch unter Windows problemlos einrichten.

FTP mit SSL überträgt auch nix im Klartext..

Da das Binary wohl gegen andere Versionen kompiliert ist, wird das nix.. es sei denn, du kompilierst selbst PHP4 aus den Quellen für Windows..

PHP4? Ernsthaft? ...

Also mit der Aktivierung von simplefb bekomme ich eine Ausgabe schon mal.. dann werde ich mal schauen, was da so los ist mit nouveau.
Wobei mir noch nicht so ganz klar ist, wieso ohne Framebuffer es keine Ausgabe gibt. Eigentlich wäre meine Erwartung, dass es dann vga text 80x25 gibt.. oder geht das nur mit CSM/BIOS und UEFI braucht zwangsweise einen framebuffer?