NTFS Image

[pa-for-opsi]

Leider habe ich keine Ahnung wie das geht! Kannst Du mir helfen? Danke.

[Anakim]

was ergibt den die Abfrage des opsiservers über nslookup? Wird der fqdn zurückgeworfen? bzw. der Aufruf von confed Editor funktioniert wohl? mit welcher Adresse? DNS wahrscheinlich?

Was für ein DNS hast du im Einsatz? MS?


Anakim

[pa-for-opsi]

Hallo an alle Beteiligten zum Thema NTFS-Image
Namensauflösung ist nicht der Grund des Scheiterns.
1. Ich habe auf dem OPSI-Server in der resolv.conf einen zweiten "nameserver" angegeben.
2 Auf dem Remote-Rechner (Windows, Putty), von wo ich alles erledige, habe ich OPSI in die /.../hosts eingetragen.
Fazit: funktioniert gut. Nun kann kann ich auch remote (Putty) opsi.ksk.local ansprechen. Also DNS ist es NICHT!

In der Fehlermeldung ist die url "https://xxxx.xx.xxxx:4447/rpc" eingetragen, "/rpc" gibt es aber nicht wie "/configed" bei
"https://xxxx.xx.xxxx:4447/configed".[b] Also liegt es an diesem "/rpc"[/b], was immer das auch sein soll. Auch der Browser scheitert natürlich bei
"https://opsi.ksk.local:4447/rpc".

Schade, ich habe viel Zeit investiert und nichts erreicht. Der Vorgang gehört zu einer Grundausstattung. Um es richtig zu stellen, ich möchte von der Idee des Images(clonen) wegkommen, aber der erste Schritt ist ein SYSPREP-Image. Nach langer Arbeit und Vorbereitung bin ich soweit ein SYSPREP-Image von einer virtuellen Maschine zu erstellen, die alle HAL's abdeckt und alle Treiber. Das MINI-Setup, das dann auf den Rechnern (es sind viele) läuft, ist zeitlich wesentlich kürzer als eine Neuinstallation und dann sollte die Software-Verteilung folgen, was mit OPSI auch ganz schön wäre, ginge aber auch mit WPKG.

Vielleicht kann auch das Skript zur OS-Installation abgeändert werden, dass auf dem Rechner nach OS-Installation wirklich nur die ISO-CD ist, die man z.B. mit nLite hergestellt hat. Ich bin an einem Punkt an dem ich wieder über das aufgeblasene und teure ALTIRIS nachdenke! SCHADE.

Gruß, pa-for-opis oder vielleicht auch pa-for-altiris.

[pa-for-opsi]

Also bezüglich DNS ist bei mir die Sache folgendermaßen gestrickt:
1. DNS setze ich bei der Installation auf meinen Router (auch Gateway) ,der wiederum routet weiter. Ich brauche den Zugriff Internet für Aktualisierung.
2. Wen alles fertig ist, füge ich auf dem OPSI-Server einen zweiten "nameserver" in der resolv.conf hinzu, lokal mit der IP des OPSI-Servers.
3. Da ich via Putty und Browser remote arbeite (Windows), lege ich hier in /../hosts auch den Server mit IP und fqdn fest.

Nun kann ich via opsi.ksk.local (nicht nur opsi oder 192.168.x.x) auch mit Putty und mit Browser (zusätzlich :4447/..) zugreifen. Was diese Angelegenheit anbetrifft ist alles OK.

Wie schon erwähnt liegt es am "/rpc" (vermute ich!).

Es wäre schön wenn wir diesen Punkt einmal lösen. Was mich wundert ist die Tatsache, dass es nur noch Ende Juni eine Frage genau zu diesem Thema gab und irgendwie hängen blieb. Dieses "ntfs-write-image" Produkt sollte einwandfrei funktionieren, ansonsten ist es kein Produkt. Image ist Image, also dieses schreiben sollte kein Problem sein und dann muss es auch noch (wahrscheinlich via ssh) auf dem OPSI-Server hinterlegt werden um es bei Bedarf auf die gewünschten Computer zu "restoren". Oder sehe ich die Sache zu einfach?

Gruß, pa-for-opsi.

[Anakim]

Moin

Hallo an alle Beteiligten zum Thema NTFS-Image
Namensauflösung ist nicht der Grund des Scheiterns.
1. Ich habe auf dem OPSI-Server in der resolv.conf einen zweiten "nameserver" angegeben.
2 Auf dem Remote-Rechner (Windows, Putty), von wo ich alles erledige, habe ich OPSI in die /.../hosts eingetragen.
Fazit: funktioniert gut. Nun kann kann ich auch remote (Putty) opsi.ksk.local ansprechen. Also DNS ist es NICHT!

Das sehe ich allerdings anders, da du den opsiserver in deine hosts eintragen musst um den DNS Namen aufzulösen hast du defenetiv ein DNS Problem. Das hilf ja nur deinem Client aber nicht deinem zu versorgendem Rechner! Ich muss keine hosts modifizieren oder weitere nameserver eintragen. Deshalb hast du defenetiv noch ein Problem.

In der Fehlermeldung ist die url "https://xxxx.xx.xxxx:4447/rpc" eingetragen, "/rpc" gibt es aber nicht wie "/configed" bei
"https://xxxx.xx.xxxx:4447/configed".[b] Also liegt es an diesem "/rpc"[/b], was immer das auch sein soll. Auch der Browser scheitert natürlich bei
"https://opsi.ksk.local:4447/rpc".

RPC ist Remote Procedure Call .. wird vom Client zur Kommunikation mit dem Server benötigt, da dein Opsiserver das offensichtlich nicht kann bzw. antwortet versuch doch mal folgendes..

Code: Alles auswählen

ps ax | grep rpc

Da sollte dann sowas bei dir rauskommen..

Code: Alles auswählen

opsiserver:~# ps ax | grep rpc
 2872 ?        Ss     0:00 /sbin/rpc.statd
 9261 pts/0    S+     0:00 grep rpc
opsiserver:~#

Wenn der rpc Prozess bei dir nicht läuft, dann sollten wir das erstmal beheben ..

Grüße
Anakim

[pa-for-opsi]

Hallo Anakim, also bei mir ist zu sehen:

2134 ? Ss 0:00 /sbin/rpc.statd
3915 pts/0 S+ 0:00 grep rpc

Vielleicht kriegen wir es hin. Grundsätzlich habe ich auch noch andere wichtige Fragen, wie z.B.
1. ob alle Clients, bzw. Gruppen per Wake On Lan gestartet werden können? Bei der Gruppenbildung via Config-Editor habe ich auch Probleme. Gruppenbildung nach gewissen Profilen hat für mich einen grossen Wert.
Wir haben viele Computer (eine Schule mit einer traumhaften Infrastruktur, wenig Geld für EDV). Profile-0 bedeutet der Teil der Sofware der allen gemeinsam ist: OS, File Manage, WinRAR, AcroR ... u.s.w
Dann habe ich 7 Profile: Profile-A (auf 46 Rechnern) , Profile-B (auf 24 Rechnern) , ... jedes Profil mit entsprechender Software. Bietet OPSI das Management für solche Fälle? Von den Features her ja, ob das dann auch funktioniert?
2. OS-Installation funktioniert gut, auch von CD nach slipstream mit nLite, aber es gibt Probleme bei der Partitionierung. "ntfs" mit zwei Partitionen läuft, stagniert bei
# Write Partition Boot Record
disk.writePartitionBootRecord(partition=1, fsType='fat32nt')
der Eintrag 'fat32nt' gefällt ihm nicht, 'ntfs' aber auch nicht. Wo kann man sich Infos holen zum Them, Parameter, oder z.B zu disk.CreatePartition u.s.w. Mir fehlt die Struktur und entsprechend die Orientierung.

Über Fargen denke ich noch nach. Gruss, pa-for-opsi.

[Neptunium]

Mojn,

Moin

Hallo an alle Beteiligten zum Thema NTFS-Image
Namensauflösung ist nicht der Grund des Scheiterns.
1. Ich habe auf dem OPSI-Server in der resolv.conf einen zweiten "nameserver" angegeben.
2 Auf dem Remote-Rechner (Windows, Putty), von wo ich alles erledige, habe ich OPSI in die /.../hosts eingetragen.
Fazit: funktioniert gut. Nun kann kann ich auch remote (Putty) opsi.ksk.local ansprechen. Also DNS ist es NICHT!

Das sehe ich allerdings anders, da du den opsiserver in deine hosts eintragen musst um den DNS Namen aufzulösen hast du defenetiv ein DNS Problem. Das hilf ja nur deinem Client aber nicht deinem zu versorgendem Rechner! Ich muss keine hosts modifizieren oder weitere nameserver eintragen. Deshalb hast du defenetiv noch ein Problem.

Da muß ich Anakim beipflichten. Du hast mit hoher Wahrscheinlichkeit ein DNS-Problem und vermutlich mußt du dich nochmal grundlegend mit diesem Thema beschäftigen. Ohne eigenen DNS wirst du bei mehr als einer Handvoll Rechner auf Dauer nicht glücklich werden. Es würde sich IMHO anbieten, auf dem Opsi-Server einen bind (oder eines der Derivate) laufen zu lassen und eine eigene Zone inklusive Reverse Zone einzurichten. Nicht nur der Server sondern jeder Client muß jederzeit die Namen und auch umgekehrt die IP-Adressen sowohl des Opsi-Servers als auch von sich selber auflösen können.

In der Fehlermeldung ist die url "https://xxxx.xx.xxxx:4447/rpc" eingetragen, "/rpc" gibt es aber nicht wie "/configed" bei
"https://xxxx.xx.xxxx:4447/configed".[b] Also liegt es an diesem "/rpc"[/b], was immer das auch sein soll. Auch der Browser scheitert natürlich bei
"https://opsi.ksk.local:4447/rpc".

RPC ist Remote Procedure Call .. wird vom Client zur Kommunikation mit dem Server benötigt, da dein Opsiserver das offensichtlich nicht kann bzw. antwortet versuch doch mal folgendes..

Code: Alles auswählen

ps ax | grep rpc

Da sollte dann sowas bei dir rauskommen..

Code: Alles auswählen

opsiserver:~# ps ax | grep rpc
 2872 ?        Ss     0:00 /sbin/rpc.statd
 9261 pts/0    S+     0:00 grep rpc
opsiserver:~#

Wenn der rpc Prozess bei dir nicht läuft, dann sollten wir das erstmal beheben .[/quote]

Da liegst du meiner Meinung nach aber falsch, Anakim. rpc hat hier nichts mit dem rpc.statd zu tun, der eh nur für nfs zuständig ist. rpc ist ein sehr altes grundlegendes Protokoll bzw. Technik, mit der Prozesse übers Netz miteinander kommunizieren können (siehe http://de.wikipedia.org/wiki/Remote_Procedure_Call). Und hier hat es erst recht primär nichts mit rpc.statd zu tun, denn hier ist es vermutlich das Protokoll, mit dem der Client mit dem configed vom Opsi-Server spricht.

Also ich würde erstmal die DNS-Problematik beheben, die vermutlich auch bei anderen Sachen auftreten wird, denn nach deiner Beschreibung kennen die Geräte in deinem Netz ja nichts zu den Namen und IPs, die sie benutzen. Unter Windows bist du vermutlich bislang auf keine Problem gestoßen, da dort WINS halt den größten Teil selber regelt. Für alle Nichtwindowssachen braucht man aber einfach eine funktionierende DNS-Auflösung, da die nicht auf WINS zurückgreifen können. Wenn danach noch Fehler bestehen, dann lassen deren Ursachen sicherlich einfacher finden.

Just my 2 Cent

Gruß

Dirk

[Anakim]

Da liegst du meiner Meinung nach aber falsch, Anakim. rpc hat hier nichts mit dem rpc.statd zu tun, der eh nur für nfs zuständig ist. rpc ist ein sehr altes grundlegendes Protokoll bzw. Technik, mit der Prozesse übers Netz miteinander kommunizieren können (siehe http://de.wikipedia.org/wiki/Remote_Procedure_Call). Und hier hat es erst recht primär nichts mit rpc.statd zu tun, denn hier ist es vermutlich das Protokoll, mit dem der Client mit dem configed vom Opsi-Server spricht.

Ich lass mich gerne eines besseren belehren .. aber ganz so falsch habe ich ja mit rpc nicht gelegen. Vielleicht kann uib hier Klarheit schaffen

Also ich würde erstmal die DNS-Problematik beheben, die vermutlich auch bei anderen Sachen auftreten wird, denn nach deiner Beschreibung kennen die Geräte in deinem Netz ja nichts zu den Namen und IPs, die sie benutzen. Unter Windows bist du vermutlich bislang auf keine Problem gestoßen, da dort WINS halt den größten Teil selber regelt. Für alle Nichtwindowssachen braucht man aber einfach eine funktionierende DNS-Auflösung, da die nicht auf WINS zurückgreifen können. Wenn danach noch Fehler bestehen, dann lassen deren Ursachen sicherlich einfacher finden.

Sehe ich genauso, einen bind aufzusetzen muss man mal sehen. Vielleicht kann pa-for-opsi erst mal schreiben wie bzw. wer seine Netzwerkdienst stellt ..

Grüße
Anakim

[pa-for-opsi]

Guten Morgen.

Also beschreiben wir die Lage zu Hause, da ich zur Zeit nicht im Büro bin.

1. Router: DNS IP des Providers, primär und sekundär
2. Rechner: Gateway der Router, DNS der Router
alles ok.

OPSI Server:
1. "hostname -f" ->opsi.ap.local
2. rpc funktioniert auch, siehe oben in den Antworten
3. ping opsi.ap.local von allen beteiligten Computern funktioniert auch
4. Browser: "https://opsi.ap.local:4447/configed" vom virtuellen Rechner, von dem ich auch das Image machen möchte, geht auch.

- könnte es etwas mit den Rechten haben. Am OPSI-Server habe ich /var/lib/opsi
"drwxr-s--- 8 pcpatch pcpatch 4096 2008-05-20 12:08 opsi"
da sehe ich keine Schreiberechte für die Gruppe, aber ein SGID ist auf "execute" gesetzt.

Gruss, pa-for-opsi.

[pa-for-opsi]

nein, die Rechte sind s auch nicht, ich habe für "/var/lib/opsi" "drwxrws---" versucht.
Leider vergeblich, pa-for-opsi.