Betriebssysteme > Solaris/x86 und OpenSolaris
Install-/Jumpserver für Solaris 2.4 x86
vab:
Naja, dann sind wohl die Zeitstempel schon beim Paketieren kaputtgewesen... :-( Das mit 1969 ist das bekannte Problem mit der Epoch. Die beginnt am 01.01.1970 um 00:00 Uhr UTC, und da war es in Kalifornien halt noch 1969, nämlich sieben Stunden zurück. In sofern hättest Du in den USA dieselben Probleme gehabt. :-)
Die Idee mit den Patchen des Install-Images ist in diesem Fall also ganz gut, wenn denn die Zeitstempel im Patch-Paket heil sind. Aber letztendlich ist er wohl egal, "irgendwas um 1994" war eine gute Idee. Alles in allem ein originelles Phänomen.
Gruß -- Volker
escimo:
Jetzt habe ich doch noch bzw wieder ein Problem.
Ich wollte mal für einen SPARC Client (SPARCstation 2) eine Netzwerkinstallation anstoßen, um zu sehen, dass es auch funktioniert. - Fehlanzeige!
Da stimmt was mit der TFTP-Konfiguration nicht.
Egal von welchem Client, ob innerhalb der VM, vom SPARC Client, vom Host der VM, bei jedem Versuch eine Datei zu laden bekomme ich...
--- Zitat ---# tftp localhost
tftp> binary
tftp> trace
Packet tracing on.
tftp> status
Connected to localhost.
Mode: octet Verbose: off Tracing: on
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
Transfer blocksize option: off
Server rexmt-interval option: off
Transfer size option: off
tftp> get inetboot.sun4c.Solaris_2.4
sent RRQ <file=inetboot.sun4c.Solaris_2.4, mode=octet>
received ERROR <code=2, msg=Access violation>
Error code 2: Access violation
--- Ende Zitat ---
Der Verbindungsaufbau ist ok, auch getestet mit anderen Diensten (telnet, ftp).
Einträge in /etc/bootparams, /etc/hosts, /etc/ethers, /etc/dfs/dfstab.conf liegen für den Client vor.
Und das witzige daran ist, bevor ich mit RPL für den x86 Install Server gearbeitet habe, funktionierte der TFTP-Zugriff ohne Probleme.
Ggf. muss ich die SMF-Konfiguration aktualisieren, da ich kurzzeitig das Root auf /rplboot umgebogen hatte. Damals war ich noch davon ausgegangen, dass für Intel auch TFTP benutzt wird und das Root-Verzeichnis ggf. anzupassen ist. Da hätte ich mich mal besser einlesen sollen. :-[
Folgende Konfiguration liegt aktuell vor:
--- Zitat ---
# svcs -a | grep tftp
online 15:22:21 svc:/network/tftp/udp6:default
# ls -l /tftpboot/
total 344
lrwxrwxrwx 1 root root 26 Aug 11 14:19 C0A83C02 -> inetboot.sun4c.Solaris_2.4
lrwxrwxrwx 1 root root 26 Aug 11 14:19 C0A83C02.SUN4C -> inetboot.sun4c.Solaris_2.4
-rwxr-xr-x 1 root root 163188 Aug 11 14:19 inetboot.sun4c.Solaris_2.4
-rw-r--r-- 1 root root 522 Aug 11 14:19 rm.192.168.60.2
lrwxrwxrwx 1 root root 1 Aug 11 14:19 tftpboot -> .
# ls -ld /tftpboot/
drwxrwxr-x 2 root root 512 Aug 11 15:10 /tftpboot/
# tail -2 /etc/inetd.conf
# TFTPD - tftp server (primarily used for booting)
tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
--- Ende Zitat ---
Ideen woran das liegen könnte?
escimo:
--- Zitat von: escimo am 11. August 2016, 15:40:22 ---Und das witzige daran ist, bevor ich mit RPL für den x86 Install Server gearbeitet habe, funktionierte der TFTP-Zugriff ohne Probleme.
Ggf. muss ich die SMF-Konfiguration aktualisieren, da ich kurzzeitig das Root auf /rplboot umgebogen hatte. Damals war ich noch davon ausgegangen, dass für Intel auch TFTP benutzt wird und das Root-Verzeichnis ggf. anzupassen ist. Da hätte ich mich mal besser einlesen sollen. :-[
--- Ende Zitat ---
... und so ist es ...
--- Zitat ---
# inetadm -l network/tftp/udp6
SCOPE NAME=VALUE
name="tftp"
endpoint_type="dgram"
proto="udp6"
isrpc=FALSE
wait=TRUE
exec="/usr/sbin/in.tftpd -s /rplboot"
user="root"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=FALSE
default tcp_wrappers=FALSE
default connection_backlog=10
# inetadm -m network/tftp/udp6 exec="/usr/sbin/in.tftpd -s /tftpboot"
# inetadm -l network/tftp/udp6 | grep exec
exec="/usr/sbin/in.tftpd -s /tftpboot"
# svcadm restart network/tftp/udp6
# pwd
/root
# tftp localhost
tftp> get C0A83C02
Received 163823 bytes in 0.2 seconds
tftp> quit
# ls -l C0A83C02
-rw-r--r-- 1 root root 163188 Aug 11 22:09 C0A83C02
--- Ende Zitat ---
"Demenz, sei gegrüßt!" :'(
EDIT:
Die interaktive Netzwerk-Installation kann dann vom OBP über "boot net - install" angestoßen werden.
Dann sieht es in etwa so aus: https://youtu.be/dircODk9lq0
vab:
Ja, das mit dem /tftpboot nervt. Neuerdings nehme ich wenn möglich immer /etc/netboot (so wie es S11 AI haben will) und lege für /tftpboot ein symlink an.
Klappt nur dann nicht, wenn man Sun Ray-Software hat, die unbedingt will, daß /tftpboot ein Directory ist...
Gruß -- Volker
Navigation
[0] Themen-Index
[*] Vorherige Sete
Zur normalen Ansicht wechseln