Posts by jumbopack

Hi,

wenn Du tatsächlich NFS verwendest, so wird der Root-User auf anonymous gemappt und hat damit keinen Schreibzugriff auf das entfernte Share. Das kannst Du umgehen, in dem Du in der /etc/exports dem Share die option no_root_squash mitgibst. Sauberer wäre es natürlich trotzdem, den VDR nicht als root laufen zu lassen.

HTHH
Jürgen

Hi

checke mal ab, ob

a) das Script überhaupt in /etc/init.d liegt und auch "vdradmind" heißt

b) das Script Ausführungsrechte besitzt, ansonsten chmod a+x /etc/init.d/vdradmind

Dann klappt's auch mit der Nachba.... oder so!

Ciao + HTHH
Jürgen

Hi,

ich glaube gelesen zu haben, dass der Schwaiger ein Topf-Clone (Topfield 4000PVR) ist. Die Dinger haben normalerweise ein eigenes, auf die Belange hin optimiertes Filesystem (z.B. 24Bit-FAT, 1MB-Junks etc.). AFAIK gibt es aber gerade im Topf-Bereich Tools zum Kopieren etc. Wenn der Schwaiger also ein Topfield-Clone ist, hast Du gute Chancen (siehe Topf-Board

HTHH
Jürgen

Hi,

Quote

das erzeugt einen Link /video-->/smb/video in /smb !!! oder nicht ?

Nö. Beachte den Slash vorne. Die Pfade sind vollqualifiziert angegeben.

cd /smb   #gehe nach "/smb"
mkdir video   #erzeugt also letztendlich das Verz. "/smb/video"
ln -s /smb/video /video  #erzeuge in "/" einen Link "video", der auf "/smb/video" verweist

Ciao
Jürgen

Moin mitnanda!

Macht's doch nicht so kompliziert. Ein Symbolic-Link tut's.

cd /smb
mkdir video
ln -s /smb/video /video

Und gut ist's.

Ciao
Jürgen

Hi,

chmod a+x startq.sh

und dann aufrufen (mit "Extension"), also /path/to/startq.sh

HTHH
Jürgen

MOD: Mist, zu langsam! /MOD

Quote

... zum geschraubten Nagel: ROTFL ... ich kugel mich gleich unter'n Tisch... den merk ich mir

Na, da leg´ ich doch gleich noch einen (thematisch sogar passenden) drauf:
"Der Meister mag´s kaum glauben, man kann auch mit dem Hammer schrauben!"

Ciao
Jürgen

Hi,

Nugman, ich hätt's nicht besser sagen können!

Quote

Für jede Aufgabe nimmt man das Werkzeug, das sich am besten dafür eignet bzw. das man für am geeignetsten hält.

100% ACK. So ist es, so soll es sein! Wer nur auf Prinzipien rumreitet, hat auf lange Sicht eh ein Problem.
Wobei ich immer mehr zu der Überzeugung komme, dass sich die sog. "Trolle" im Heise-Forum gegenseitig schon lange nicht ernst nehmen und sich eher an den provozierten Reaktionen der Troll-Fütterer erfreuen. Hat langsam was von Douglas Adams (Beherrschung der Erde durch Mäuse, oder waren's Delfine?).

Quote

Du haust ja auch die Nägel nicht mit dem Schraubenzieher in die Wand.

Hierzu möchte ich ergänzend bemerken, dass eine genagelte Schraube immer noch besser hält als ein geschraubter Nagel!

Ciao
Jürgen

Hi,

ich denke, es gibt viele Gründe, warum dies so ist. Die zwei aus meiner Sicht wichtigsten:

1) Bei Windows legt M$ alleine die Richtlinien fest. Im Sinne einer Standardisierung und den damit verbundenen Synergien was Support, Wartung etc. betrifft ist dies unbestritten von Vorteil. Der Nachteil, den man sich damit erkauft ist, dass man Weiterentwicklungen und Verbesserungen teilweise blockieren muss, um seine "Standards" zu halten. Man denke nur an diese völlig starre und unpraktische Laufwerksbuchstaben-Geschichte. Und es ist noch nicht sooo lange her, da war jedes Windows eine auf DOS aufgepfropfte GUI, nichts weiter.
Unix (auch Linux ist "nur" ein Unix-Dialekt) hingegen hat eine nunmehr 35-jährige Entwicklungs- und Reifezeit hinter sich. Die verlief teilweise recht turbulent. Guggst Du mal hier auf den Unix-Stammbaum (Seite 10).
Die beiden "Hauptlinien" BSD und AT&T haben sich durch kreuzweise Portierungen immer wieder gegenseitig beeinflusst. Uns do schaut In jedem der Kästchen z.B. das Filesystem-Layout ein bisschen anders aus. Und trotzdem läuft's und jeder Unix-SW-Hersteller schafft es ohne Probleme, seine Produkte auf allen nenneswerten Derivaten zum Laufen zu kriegen. Das geht halt wiederum nur, weil Unix aufgrund der frühen Aufspaltung bereits von Anfang an so flexibel sein musste, und sich z.B. auf feste Pfade (oder gar LW-Buchstaben!) nicht verlassen konnte.

2) Unix ist und war von Anfang an Netzwerk- und Mehrbenutzersystem (entgegen der Meinung vieler ist das auch ein WinXP Pro heute noch immer nicht. Erst die Terminal-Services (früher Citrix) machen ein Win zum Multi-User-System). Es musste also schon immer eine Möglichkeit geben, Dateien (auch Konfigurationen) nach Usern getrennt und separiert von den Systemdateien abzulegen, zu verwalten und auch zu nutzen. Das einzige, was hier funktioniert ist der dezentrale Ansatz. Der Nachteil ist klar: man muss immer wissen, wo man hinlangen muss. Allerdings haben sich ja auch "Pseudostandards" (z.B. /usr/local/...) ergeben, die wahrscheinlich 90% der Fälle abdecken.
Der unbestrittene Vorteil aber: die Systemdateien und die Systemkonfiguration bleiben auf diese Weise sauber! Keine "DLL-Hell", keine Registry oder System.ini mit Restfragmenten längst deinstallierter (vermeintlich deinstallierter!) Software, keine Reboot-Orgien bei Konfig-Änderungen, keine Viren/Würmer/Trojaner/Spyware von relevanter Bedeutung, sehr hohe Systemstabilität. Alleine das ist es wert, im Zweifelsfall ein bisschen nach der richtigen .conf zu suchen (normalerweise ist's ja auch dokumentiert, wo's liegt).

Es gab auch im Unix-Bereich ein paar Versuche, Standards bzgl. Filesystemlayout, GUI, Bibliotheken etc. zu setzen. Die scheiterten aber an den unterschiedlichen wirtschaftlichen Interessen der beteiligten Firmen (Stichworte: OSF, UI, COSE, UnitedLinux...)

Also, langer Rede (nennt mich "olafh...";-) ) kurzer Sinn: es hat vor- und Nachteile, aber es ist halt nun mal so, und man gewöhnt sich dran. In meinen bald 20 Jahren Unix-Erfahrung mit den verschiedensten Derivaten hat's zumindest immer geklappt!

Ciao
Jürgen

Hmmm...
auf den leeren Sockel kann man bestimmt ein CAM-Modul hinpfriemeln. Oder ist's der RGB-Ausgang???

Moin, Jarny

Quote

:1,$s/SVHS/S-Video/g

Damit würdest Du im Editor "vi" global SVHS gegen S-Video ersetzen. Dann wäre Deine Aussage sinnvoll.

SVHS ist nämlich ein von JVC entwickeltes Verfahren, um die Auflösung von Videorecorden (auch: VCR; im heutigen Digitalzeitalter archaisches, aber immer noch vielfach verwendetes Gerät, um Bild- und Toninformationen auf endlich langen, magnetisch beschichteten Kunststoffbändern aufzuzeichnen und von dort aus wiederzugeben) zu steigern. VHS: 250 Zeilen, SVHS: 400Zeilen.
S-Video ist dagegen die Übertragung analoger Video-Signale getrennt nach Chrominanz und Luminanz.

Da gibts' im Forum schon einige (zuweilen heitere) Threads dazu.

Ciao
Jürgen

Moin,

ist ja alle schön und gut, aber

:1,$s/SVHS/S-Video/g

Oberlehrerhaftes Ciao
Jürgen

PS: Hatten wir schon lange nicht mehr...

Quote

Für ganz risikofreudige:
* Start-Prepaid (gibts noch ne Woche...) mit Kabel-dBoxII für 99 Euro holen
* Merken, daß du doch Sat hast und das der Technik-Abteilung bei Premiere irgendwie beibringen
* Receiver für 34 Euro in die Sat-Ausgabe umtauschen lassen

* und dann einen Galaxy ohne LAN-Schnittstelle bekommen!

Fazit: (99+34) EUR verbrannt phoenix und widdernix

wirklich nur für risikofreudige....

Ciao
Jürgen

wie gesagt:

vertrauenswürdige Hosts UND vertrauenswürdige Kommunikationskanäle, dann würde ich's (vielleicht ) ohne machen.

Keys erzeugst Du mit ssh-keygen. Lies Dich am besten vorab mal etwas in die Materie ein. Es ist -finde ich- ein spannendes Thema (Alice und Bob und Blowfish und all diese Dinge...)

Ciao
Jürgen

Quote

Und wozu brauch ein VDR sowas?

Solange Du sicher bist, dass Du auf Deine Systeme (VDR oder nicht, ist ja egal) immer nur
a) von vertrauenswürdigen (also sicher nicht gehackten oder mit durch Spyware o.ä verseuchten und mit Backdoors versehenen) Rechnern zugreifst
b) über einen sicheren Kommunikationsweg zugreifst

brauchst Du es natürlich nicht. Bist Du 100%ig sicher?

Aber schaden tut's ja nicht und mehr Aufwand als telnet ist's auch nicht (selbst mit pubkey-Authentication).

Ciao
Jürgen

Ahoi,

Quote

Was machen die SSH-Keys, wozu sind die überhaupt dabei?

SSH (Secure SHell) ist ein Ersatz für telnel/rlogin/rsh etc., der sich dadurch auszeichnet, dass verschlüsselt kommuniziert wird und somit keine Paßwörter mitgeschnitten oder Verbindungen gehijacked werden können. Die Keys werden benötigt zum einen zur Identifikation ("spreche ich wirklich mit demjenigen, mit dem ich sprechen will?") und zum anderen zur Vereinbarung des Schlüssels, mit dem die Verbindung anschließend kryptiert wird.

Im Internet findet sich sicher eine Fülle an Informationen zu Funktionsweise und Ausgestaltung der diversen ssh-Implementierungen.

Bei Deinem Mandrake ist wahrscheinlich kein SSH-Server installiert, sonst hättest Du sicher Keys.

HTHH
Ciao
Jürgen

Hi,

also bei mir ergibt das sshd -ddd -D folgendes:

Quote

debug1: Seeding random number generator
debug1: sshd version OpenSSH_3.0.2p1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 22 on ::. Server listening on :: port 22.

Display More

Er "meckert" zwar auch, dass er keine RSA1-Files findet, aber der ssh-Server startet trotzdem und arbeitet auch definitv nur nach Protokoll 2. Ist also nur informativ. Evtl. sogar falsch, da er ja auch den Typ 2 RSA-Key als "type 1 RSA" bezeichnet.

Die 3 Host-Key-Einträge sind
Type 1 RSA: /etc/ssh/ssh_host_key
Type 2 RSA: /etc/ssh/ssh_host_rsa_key
Type 2 DSA: /etc/ssh/ssh_host_dsa_key

wobei Type 1 RSA und Type 2 DSA eh defaultmäßig gesucht werden und deshalb in der sshd_config eigentlich auch weggelassen werden können (sofern man keine anderen Namen verwendet).

Ciao
Jürgen

Ahoi,

hast Du eine DBoxII?

Ich hatte mich mal in meiner Vor-VDR-Zeit um eine bemüht (wg. Ethernet-Anschluss und der Linux-Geschichte). Premiere rückt schon lange keine SAT-DBoxII mehr raus (wenn man Glück hat, bekommt man eine "refurbished", also einen Rückläufer, aber das wird nicht zugesagt). Oder man zahlt bei e*ay horrende Preise für die Teile. Da bastel ich mir dann lieber einen schicken Fanless-Client im Designer-Gehäuse, und der kann mehr als die DBox...

Ciao
Jürgen

Hi,

Quote

Key ist not a RSA1 key

ich würde aus Sicherheitsgründen eh nur SSH Version 2 zulassen. (Eintrag "Protocol 2" in sshd.conf).
Und wenn schon ssh, dann auch ohne Password-Authentication, sondern nur mittels passphrase-geschütztem Key.

Vielleicht zu paranoid, mag sein. Aber schaden tut's nicht.

Ciao
Jürgen

Hi,

ein paar Ideen:

1) Du darfst für die Host-Keys keine Passphrase angeben
2) Der private-Key MUSS die Rechte 600 haben
3) Der public-Hostkey SOLL die Rechte 644 haben (der wird aber eigentlich gar nicht benutzt)
4) Die zum Key passende Protokollversion muss in der sshd_config aktiviert sein
5) Die Key-Namen müssen ebenfalls in der sshd_config bekannt gemacht werden.

Sieht so aus:

...
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
...

Du kannst den sshd mal so starten:

sshd -t (Test des Config-Files und der Key-Integrität)

oder auch

sshd -ddd -D (Debug-Level 3 und keine Dämonisierung)

dann siehst Du auf der Konsole und im Syslog was abgeht.

HTHH
Jürgen