TheFinn

Hmm, ohne mich jetzt zu weit aus dem Fenster lehnen zu wollen, sage ich mal, daß das nicht geht und das das auch gut so ist. Was Du da versuchst ist das Auslesen von Client-Informationen durch eine Webseite, die Du ggfs von "irgendwoher" geladen hast. Eine Webseite bzw. die in ihr enthaltenen Skripte dürfen doch nicht einfach meine Umgebungsvariablen auslesen und damit hantieren? Mindestens einmal wird Dein Nutzer seinen Namen also schon noch eingeben müssen, danach kannst Du ihn Dir ja über hidden fields oder auch Cookies merken. Die Tatsache, daß beim Eintrag von %username% in die Adresszeile des Browsers die Umgebungsvariable durch ihren Wert ersetzt wird, ist ja eine Komfortfunktion im Kontext der Browserbedienung, auf die die Rendering Engine, also die geladenen Seiten keinen Zugriff haben (dürfen!). Sonst könnte ja über den gleichen Mechanismus eine Webseite beliebige lokale Dateien öffnen und an einen Herrn und Meister im Netz verschicken.

Das Administratorkonto legt Windows bei der Installation ja ohnehin schon selber an. Das Problem ist, daß der Nutzer, den es für Dich anlegt (also z.B. "dschuli"), automatisch Administratorrechte erhält. Was Du (i.A. und an einem einzelnen Rechner, vgl. mein voriges Posting) tun solltest, ist also, dem Administratorkonto ein "anständiges" Kennwort verpassen und Dein eigenes Konto in die Gruppe "eingeschränkte Nutzer" packen. Korrektur: unter XP heißt die Gruppe nur noch Benutzer, entspricht dem, was unter 2000 die "eingeschränkten Benutzer" waren.

Meine Äußerung war sicher verkürzt und vielleicht auch etwas "süffisant". Ja, es finden sich sicher auch Szenarien, in denen die Kapselung von administrativen Rechten in ein eigenes Konto irrelevant ist. Dann sollte man allerdings sehr genau wissen, was man da tut, genauer als es beim Threadstarter vermutlich (noch) der Fall ist (soll kein Vorwurf sein, 1. Klasse kommt halt vor der 2...). In einer Domäne (Du sprichst von "Clients"...) sieht die Sache eh nochmal etwas anders aus insofern als die wirklich wichtigen Dinge da unabhängig von den Clients geschützt werden. Es gibt halt Admins, denen es egal ist, wenn sich jemand seinen Client zerschießt, der ist schnell neu installiert. Es gibt aber auch andere, die finden es besser, Gürtel und Hosenträger zu tragen.

Hmm, scheint so, denn... ...das ist nun wirklich absolutes Grundwissen: ein Administrator darf alles, also auch alles versaubeuteln. vgl. Sicher durch Verzicht

Dann hast Du ihn doch schon falsch aufgesetzt. Es gibt immer mindestens zwei Nutzer in einem NT-basierten System: einen mit Administratorrechten und einen ohne. Security Identifier - Wikipedia

Wie ich schon schrieb, habe ich das immer nur für einzelne User gemacht, grundsätzlich sollte es aber so wie von Dir gesagt auch gehen (abgesehen davon, daß in ProfilesDirectory erstmal nicht "C" steht sondern "%SystemDrive%"... Mach Dir aber klar, daß während Deiner Änderung an der Registry zahlreiche Dateien geöffnet sind und auch laufend auf die Registry zugegriffen wird. Das ist der Grund, weshalb ich dies in der Vergangenheit immer nur für User gemacht habe, die in diesem Moment gerade nicht angemeldet waren... Eventuell kannst Du den Key aber hiermit auch offline ändern und das Verzeichnis anschließend mittels irgendeines Live-Linux-Systems auf die andere Partition schaufeln. Aber nicht mich anmeckern, wenn Dir dabei irgendwas "explodiert"...

HKLM: gängige Abkürzung für "HKEY_LOCAL_MACHINE" in der Registry...

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList ist Dein Freund. Dort findest Du für jeden User ein Verzeichnis, in dem es den Schlüssel ProfileImagePath gibt, in dem der Ort für die "Dokumente und Einstellungen" angegeben ist. Einfach dort setzen und anschließend den Krempel kopieren. Dabei darauf achten, daß alles aus diesem Ordner kopiert wird und daß der Nutzer beim nächsten Anmelden auch die nötigen Rechte für das neue Verzeichnis hat. Oft benutzt, nie Probleme gehabt. Nachtrag: Direkt unter HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList gibt es einen Schlüssel ProfilesDirectory, der das wohl für alle regelt, den habe ich aber nie benutzt...

Äh, das hier ist das Linux+Unix-Forum. Und um mal ein Loriot-Zitat abzuwandeln: "Ein Linux ohne SSH ist möglich, aber sinnlos..."

Nö. Der Threadstarter suchte ja nach einem Weg, den Krempel ohne Zwischenspeicherung auf Server1 nach Server2 zu kopieren. Das geht relativ elegant so: ssh server1 "ssh server2 \"cat > /tmp/test.txt\"" < test.txt (Viele vergessen, daß einem bei SSH auf der remote machine durchaus stdin und stdout zur Verfügung stehen... ) Voraussetzung ist allerdings public key authentication zumindest auf der Strecke von server1 nach server2.

Dann empfehle ich Dir, einfach mal mit ein paar Produkten 'herumzuspielen'. Mit den 30-Tages-Test-Lizenzen von VMware (ESX/Infrastructure) kann man wirklich eine ganze Menge lernen. Aber gönn auch der Xen-Schiene einen Blick, um die Unterschiede zu verstehen (vollständige vs. Paravirtualisierung). Gleich vorab: Vorsicht, wenn Du Server/Anwendungen virtualisieren sollst, die auf eine genaue Zeit angewiesen sind, damit machst Du ein übles Faß auf. VMware bietet (zu ihren Produkten natürlich...) sehr ausführliche Dokumentationen an (guter Einstiegspunkt ist m.E. hier) und auch in der "Community" findet man interessante Dinge. Dazu lese ich gerade dies hier: Troppens et al.: Speichernetze, sehr empfehlenswert. Beides sehr interessante Themen, aber bring etwas Zeit mit, Schnellschüsse in dem Bereich können verdammt teuer werden, würde ich sagen...

Ja, das wollte ich auch gerade noch vorschlagen. Der Abgleich scheint ja zunächst zu klappen: send_file_list done file list sent send_files starting rsync: connection unexpectedly closed (4 bytes received so far) [sender] Besonders diese ersten vier Byte wären ja evtl. interessant (wenn's denn jedesmal vier sind). Gerade weil der Abgleich zunächst klappt, das Schreiben dann aber nicht mehr (jedenfalls nicht beim zweiten Mal), kam mir gerade auch noch das Thema Zugriffsberechtigungen in den Sinn. Bei der ACL-Unterstützung von rsync scheint wohl das letzte Wort noch nicht gesprochen zu sein, wenn ich mir dies hier (gerade aus Zeitmangel nur sehr flüchtig) anschaue. Vielleicht gibt's da ja noch eine Spur?

Jetzt bitte nicht lachen, aber: indem Du dem yes einen leeren String als Argument mitgibst, also yes '' | blub.sh Der Antwortstring von yes (per Default 'y') wird mit einem CR abgeschlossen. Die Tatsache, daß Du in der Ergebnisdatei Deines Skriptes auch mehrere Zeilen hattest, liegt an Deiner Benutzung von echo im Skript. Du hast das CR nicht von der Eingabe eingelesen sondern nur mit dem Skript ausgegeben. Das kannst Du sehen, indem Du einfach mal alle read-Anweisungen bis auf die erste rauslöschst. Dann hast Du eine Datei, die genauso viele zeilen hat wie die mit den read-Anweisungen erzeugte. Dann steht bei blub.sh <<<a sogar das 'a' in den ersten vier Zeilen (weil Du es nach dem ersten read nicht mehr veränderst), bringt Dir aber nix, weil das Skript das 'a' viermal von der Eingabe einlesen soll...

Sieht ja erstmal nicht dramatisch aus, ich dachte zuerst an eine unglückliche Verkettung von Aufrufoptionen, wie hier Tritt das Problem auch auf, wenn Du die compression mal rausnimmst?

Und 'ne genaue Angabe, was Du gemacht hast, erst mal Rsync kennt etwa 100 Aufrufoptionen, welche hast Du benutzt?

Auch das ist jetzt off-topic, muß aber sein: Reinhold, wo kriegt man diesen wunderschönen A*sch mit Ohren für den Schreibtisch???

Der Windows Home Server enthält wohl einen RDP-Proxy (Hörensagen bzw. Google), ist es das, was Du suchst?

Na ja, das bash-Manual sagt dazu folgendes: Here Strings A variant of here documents, the format is: <<<word The word is expanded and supplied to the command on its standard input. Das word ist dabei in Deinem Fall, hmm, ein maskiertesn Leerzeichen? Weißraum kann so tricky sein... Wenn Du das Leerzeichen zwischen den beiden Backslashes wegläßt, mußt Du übrigens am Ende der Zeile nur einmal die Enter-Taste drücken. Was hier letztlich passiert, ist einfach, daß Du Dein Skript einen Zeilenwechsel von der Standardeingabe einlesen läßt. Das Problem dabei (und deswegen hatte ich Dir das Programm yes empfohlen), daß dieser Zeilenwechsel nur einmal eingelesen wird. Bei den folgenden Aufrufen von read in Deinem Skript, greift folgende Eigenart dieses shell builtin: Das kannst Du auch überprüfen, indem Du statt des Zeilenwechsels mal ein a übergibst, also ./script.sh <<< a aufrufst. Das a steht dann nur in einer Zeile Deiner Ausgabedatei. Es hängt nun von dem Skript ab, das Du letztendlich benutzen willst, ob es damit klarkommt. Wenn dort auch immer read benutzt wird und leere Werte als Bestätigung OK sind, kein Problem. Falls das Skript allerdings auf irgendeine ausgefeiltere Art explizit ASCII-Zeichen 13 einzulesen versucht und einen leeren String nicht akzeptiert, funktioniert es halt nicht mehr.

Guten Morgen allerseits! Nach längerer Wartezeit hat mein Ausbildungsleiter nun endlich einen Kommentar zu meinem Vorschlag für einen Projektantrag abgegeben. Die einzige bedeutsame Kritik bezog sich auf meine Zeitplanung. Er meinte, ich solle alle Blöcke von mehr als vier Stunden auf jeden Fall in kleinere Blöcke aufteilen. Wie sehen die mitlesenden Prüfer diesen Ratschlag, wird das tatsächlich gerne gesehen? Es kommt mir sehr starr formalistisch vor und ich müßte mir halt schon etwas 'aus den Fingern saugen', um diese Forderung zu erfüllen. Vielleicht kann ja doch auch jemand aus diesem Forum mal einen Blick auf meinen Projektantrag werfen, ich hätte wirklich gerne eine zweite Meinung dazu. Ich hatte den Antrag vor 'längerer' Zeit schon mal unter http://forum.fachinformatiker.de/abschlussprojekte/111929-rfc-projektantrag-fisi-storage-anbindung-blade-frame.html zur Diskussion gestellt, darauf jedoch leider kaum Feedback erhalten. Ja, ich weiß, daß die Prüfer, die hier 'ehrenamtlich' tätig sind, genug zu tun haben, ich weiß Euren Einsatz auch durchaus zu schätzen und verstehe, daß 'Push'-Postings nicht gerne gesehen werden. Nachdem mein ursprünglicher Thread aber mittlerweile alt genug ist, um in der Standardeinstellung nicht mehr sichtbar zu sein, halte ich es dennoch für legitim, in Form dieser 4-Stunden-Frage zumindest einen zweiten Versuch zu starten. Für einen dritten wird ohnehin keine Zeit mehr sein, da am 31.1. der Abgabetermin ist... Ach ja, mein Posting vom 14.1. in o.g. Thread ist die relevante Fassung, nicht das erste Posting vom 10.1.!

Ich meine das hier: Documentation: Apache HTTP Server - The Apache HTTP Server Project Für SSL insbesondere: Apache SSL/TLS Encryption - Apache HTTP Server

Na, Du mußt dem Server schon sagen, wo er das Zertifikat findet, das er dem Browser präsentieren soll. Und einiges anderes mußt Du ihm auch noch sagen, SSLCertificateFile war nur ein (willkürliches) Beispiel, das ich gerade nochmal im Apache-Handbuch nachgeschlagen habe, um mich selber zu vergewissern :floet:, ist schon eine Weile her. Das Handbuch hat übrigens auch recht ausführliche Informationen dazu, wie man SSL mit dem Apache konfiguriert. Auch die mitgelieferte Konfigurationsdatei enthält in den Kommentarzeilen viele nützliche Hinweise und Beispiele, von denen man ausgehen kann. Die SSL-Konfiguration hier jetzt komplett zu erklären, würde glaube ich etwas den Rahmen sprengen...

Ja. SSL spielt sich auf der Transportschicht ab, da kann es nicht auf DNS-Namen, also vor dem Auflösen der Adresse passieren. Die SSLCertificateFile-Direktive ist laut Handbuch auch im Kontext "Virtual Host" möglich, also: ja, Du kannst für jeden vhost ein eigenes Zertifikat erzeugen. Bei postfix sieht das übrigens leider anders aus, was ich schon des öfteren bedauert habe...

Der Klassiker für so etwas ist eigentlich gnuplot (gnuplot homepage), ich kann Dir bloß nicht sagen, wie einfach oder schwer es ist, das Ding auf 'Eye Candy' oder zur Corporate Identity kompatible Designs zu trimmen. Das ist vermutlich nicht unbedingt seine Stärke, da es eher aus der wissenschaftlichen Visualisierung kommt. Zur Aufbereitung von Zahlenkolonnen zu Grafiken bzw. Diagrammen jedenfalls sehr leistungsfähig und flexibel...

Schon mal die man page zu yes(1) gelesen?

Hmm, stelle gerade fest, daß Paragon NTFS for Linux das wohl kann. Dummerweise ist eine Linux-Installation auf der Kiste aber keine Option und ich glaube kaum, daß die Paragon-Software auf irgendeinem Live-System als Trial integriert ist...