ssh Verbindung mit einem Skript
Harald Boss
Hier die Verbindungszeile:
ssh -l Benutzer1 pc-desktop
Wie kann ich nun das Passwort integrieren?
Bernd Hohmann
> Ich möchte eine ssh Verbindung mit einem Skript herstellen.
> Hier die Verbindungszeile:
>
> ssh -l Benutzer1 pc-desktop
>
> Wie kann ich nun das Passwort integrieren?
Gar nicht, geht nur über SSH Keys.
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
Paul Muster
> Harald Boss schrieb:
>> Ich mï¿œchte eine ssh Verbindung mit einem Skript herstellen.
>> Hier die Verbindungszeile:
>>
>> ssh -l Benutzer1 pc-desktop
>>
>> Wie kann ich nun das Passwort integrieren?
>
> Gar nicht, geht nur ï¿œber SSH Keys.
Und die Antwort auf die nï¿œchste Frage ist "ssh-agent".
mfG Paul
Bernd Hohmann
>> Gar nicht, geht nur über SSH Keys.
>
> Und die Antwort auf die nächste Frage ist "ssh-agent".
Und die Antwort auf die Übernächste Frage ist (zum Jahresende
funktionieren Kristallkugeln wohl am besten):
mkdir -m 0700 ~/.ssh/
Keygen: ssh-keygen -t dsa
vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach ~/.ssh/
kopieren
Schlüssel auf remote zufügen:
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
SSH Verbindung trennen, neu anmelden. Neues login geht jetzt ohne Kennwort
Nur noch gesicherte Verbindungen zulassen:
sudo nano /etc/ssh/sshd_config und Eintrag
„PasswordAuthentification=no“ setzen.
sudo /etc/init.d/ssh restart
Hauke Laging
> Ich möchte eine ssh Verbindung mit einem Skript herstellen.
> Hier die Verbindungszeile:
>
> ssh -l Benutzer1 pc-desktop
>
> Wie kann ich nun das Passwort integrieren?
Mit expect. Aber die Variante mit den Schlüsseln ist besser.
CU
Juergen Ilse
Harald Boss <haral...@hotmail.com> wrote:
> Ich möchte eine ssh Verbindung mit einem Skript herstellen.
> Hier die Verbindungszeile:
>
> ssh -l Benutzer1 pc-desktop
>
> Wie kann ich nun das Passwort integrieren?
Gar nicht. Wenn man automatisierte ssh-Logins benoetigt, verwendet man
Authentifizierung per ssh-Keys.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Harald Boss
> Paul Muster schrieb:
>
>>> Gar nicht, geht nur über SSH Keys.
>>
>> Und die Antwort auf die nächste Frage ist "ssh-agent".
>
> Und die Antwort auf die Übernächste Frage ist (zum Jahresende
> funktionieren Kristallkugeln wohl am besten):
>
> mkdir -m 0700 ~/.ssh/
>
> Keygen: ssh-keygen -t dsa
>
> vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach ~/.ssh/
> kopieren
>
> Schlüssel auf remote zufügen:
>
> cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
>
> SSH Verbindung trennen, neu anmelden. Neues login geht jetzt ohne Kennwort
>
> Nur noch gesicherte Verbindungen zulassen:
>
> sudo nano /etc/ssh/sshd_config und Eintrag
> „PasswordAuthentification=no“ setzen.
>
> sudo /etc/init.d/ssh restart
>
>
> Bernd
>
Danke SSH Keys das hilft mir weiter.
Harald
Martin Schmitz
> vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach ~/.ssh/
> kopieren
>
> Schlüssel auf remote zufügen:
>
> cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
Blödsinn. 'man ssh-copy-id'.
> sudo nano /etc/ssh/sshd_config und Eintrag
> „PasswordAuthentification=no“ setzen.
Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
übrigens 'vi'.
Martin
Juergen Ilse
Martin Schmitz <ne...@rmz.ath.cx> wrote:
> Bernd Hohmann wrote:
>> vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach ~/.ssh/
>> kopieren
>> Schlüssel auf remote zufügen:
>> cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
> Blödsinn.
Nein.
> 'man ssh-copy-id'.
DESCRIPTION
ssh-copy-id is a script that uses ssh to log into a remote machine
(presumably using a login password, so password authentication should
be enabled, unless you've done some clever use of multiple identities)
Und in dem Script findest sich dann folgende Zeile, die bis auf das "remote
ausfuehren per ssh" und die "Quelle" fuer den public-key so ziemlich genau
das tut, was Bernd geschrieben hat (abgesehen vom erstellen von ~/.ssh falls
es das noch nicht gibt) ...
{ eval "$GET_ID" ; } | ssh ${1%:} "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1
>> sudo nano /etc/ssh/sshd_config und Eintrag
>> „PasswordAuthentification=no“ setzen.
>
> Und nochmal Blödsinn,
Nein.
> gleich doppelt und dreifach. Der Editor heißt übrigens 'vi'.
Der Editor heisst so, wie der bevorzugte Editor des jeweiligen Users.
Auch wenn das bei mir tatsaechlich "vi" waere (i.d.R. ein "nvi" und
nicht so ein aufgeblasenes Monster wie "vim") muss das nicht bei allen
Usern so sein. Fuer einen "Linux-Neuling" ist nano i.d.R. gar keine
so schlechte Wahl (und z.B. bei gentoo ist nano der Default-Editor,
solange man das nicht explizit umsetzt).
Kurzum: Bernds Antwort war um etliche Groessenordnungen hilfreicher
als deine.
Bernd Hohmann
>>> sudo nano /etc/ssh/sshd_config und Eintrag
>>> „PasswordAuthentification=no“ setzen.
>>
>> Und nochmal Blödsinn, gleich doppelt und dreifach.
>>
>> Der Editor heißt übrigens 'vi'.
Es steht alles drin, mit dem ein Newbie nicht sofort gegen die Wand fährt.
Tip: ISBN 3458344713
Oliver Schad
> Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
> übrigens 'vi'.
*Der* Editor? Unter einem Linux/Unix? Wolltest du einen Flamewar
anzetteln?
mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Karsten Kruse
>> Der Editor heißt übrigens 'vi'.
> *Der* Editor? Unter einem Linux/Unix? Wolltest du einen Flamewar
> anzetteln?
Flamewar? Nicht nötig. Mit ,,Der Editor'' ist alles gesagt was man dazu
sagen kann.
Karsten
--
() My homepage is http://www.tecneeq.de/ and your homepage sucks¹!
<\/>
_/\_ ¹) Unless it has animated gifs from 1996, then it rocks!
Christian Schneider
> Martin Schmitz wrote:
>
>> Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
>> übrigens 'vi'.
>
> *Der* Editor? Unter einem Linux/Unix? Wolltest du einen Flamewar
> anzetteln?
vi(1) ist IEEE Std 1003.1 und somit in jeder Linux-/Unixdistribution
enthalten (wenn nicht, ist sie nicht konform zu POSIX).
[ Fup'2 => de.comp.editoren ]
--
Linux is for people who hate Windows | Christian 'strcat' Schneider
FreeBSD is for people who hate Linux | http://www.strcat.de/
NetBSD is for people who hate OpenBSD | http://www.strcat.de/blog/
OpenBSD is for people who hate everything | http://www.strcat.de/rtfm/
Juergen Ilse
Christian Schneider <str...@gmx.net> wrote:
> Thus spake Oliver Schad (nospam.spa...@oschad.de):
>> Martin Schmitz wrote:
>>> Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
>>> übrigens 'vi'.
>> *Der* Editor? Unter einem Linux/Unix? Wolltest du einen Flamewar
>> anzetteln?
> vi(1) ist IEEE Std 1003.1 und somit in jeder Linux-/Unixdistribution
> enthalten (wenn nicht, ist sie nicht konform zu POSIX).
ed(1) wirst du mindestens genauso haeufig antreffen und der ist IIRC
sowohl in der POSIX- wie auch in allen SuS-Spezifikationen genannt.
Insofern muesste man wohl eher ed als "den" Editor bezeichnen (wenn
man denn ueberhaupt einem diese Bezeichnung goennt) ...
> [ Fup'2 => de.comp.editoren ]
Ignoriert, da ich die Gruppe nicht lese und zumindest diese Korrektur
auch nach hierhin gehoert ...
Realname [m]
> Hallo,
>
> Christian Schneider <str...@gmx.net> wrote:
>> Thus spake Oliver Schad (nospam.spa...@oschad.de):
>>> Martin Schmitz wrote:
>>>> Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
>>>> übrigens 'vi'.
>>> *Der* Editor? Unter einem Linux/Unix? Wolltest du einen Flamewar
>>> anzetteln?
>> vi(1) ist IEEE Std 1003.1 und somit in jeder Linux-/Unixdistribution
>> enthalten (wenn nicht, ist sie nicht konform zu POSIX).
>
> ed(1) wirst du mindestens genauso haeufig antreffen und der ist IIRC
> sowohl in der POSIX- wie auch in allen SuS-Spezifikationen genannt.
> Insofern muesste man wohl eher ed als "den" Editor bezeichnen (wenn
> man denn ueberhaupt einem diese Bezeichnung goennt) ...
ed ist selbstverständlich *kein* Editor in diesem Sinne. Daher ist dein
Einwurf auch ziemlicher Unsinn, wie du näherungsweise auch schon selbst
erkannt hast. Was dich leider nicht davon abhielt, es trotzdem in die weite
Welt hinauszuposaunen. "Herr Lehrer, ich weiß was!!11!"
>> [ Fup'2 => de.comp.editoren ]
>
> Ignoriert, da ich die Gruppe nicht lese und zumindest diese Korrektur
> auch nach hierhin gehoert ...
Welche Korrektur?
Realname [m]
> Der Editor heisst so, wie der bevorzugte Editor des jeweiligen Users.
> Auch wenn das bei mir tatsaechlich "vi" waere (i.d.R. ein "nvi" und
> nicht so ein aufgeblasenes Monster wie "vim") muss das nicht bei allen
> Usern so sein. Fuer einen "Linux-Neuling" ist nano i.d.R. gar keine
> so schlechte Wahl (und z.B. bei gentoo ist nano der Default-Editor,
> solange man das nicht explizit umsetzt).
vim aufgeblasen? Weil er Umlaute kann? *lol*
Martin Schmitz
>> 'man ssh-copy-id'.
>
> Und in dem Script findest sich dann folgende Zeile, die bis auf das
> "remote ausfuehren per ssh" und die "Quelle" fuer den public-key so
> ziemlich genau das tut, was Bernd geschrieben hat (abgesehen vom
> erstellen von ~/.ssh falls es das noch nicht gibt) ...
Eben. Man erfindet das Rad nicht zweimal.
>>> sudo nano /etc/ssh/sshd_config und Eintrag
>>> „PasswordAuthentification=no“ setzen.
>>
>> Und nochmal Blödsinn,
>
> Nein.
Welchen Nutzen hat es denn, die PasswordAuthentification auszuschalten?
>> gleich doppelt und dreifach. Der Editor heißt übrigens 'vi'.
>
> Der Editor heisst so, wie der bevorzugte Editor des jeweiligen Users
> [...] Fuer einen "Linux-Neuling" ist nano i.d.R. gar keine so
> schlechte Wahl
Klar, wenn er sich ein Exotensystem schaffen möchte, welches das einzige
bleibt, mit dem er umgehen kann. Möchte er aber auch an anderen
Linux/Unix-Kisten nicht verzweifeln, gehört zum Einstieg auch ein
kleiner Grundkurs in vi.
Martin
Martin Schmitz
> vim aufgeblasen? Weil er Umlaute kann? *lol*
[dakini]~$ ls -l --sort=size -r /usr/bin/nvi /usr/bin/elvis /usr/bin/vim
-rwxr-xr-x 3 root root 30354 2009-04-05 15:39 /usr/bin/nvi*
-rwxr-xr-x 1 root bin 437596 2004-02-22 07:25 /usr/bin/elvis*
-rwxr-xr-x 1 root root 4192356 2009-08-25 03:04 /usr/bin/vim*
4MB für was, was man auch in 30K erledigen kann, das nenne ich auch
aufgeblasen.
Martin
Realname [m]
Mein vim-Executable hat nur ca. 1.7 MB, so kompiliert:
--enable-gui=no
--disable-nls
--without-x
--enable-multibyte
--with-features=huge
Letzteres auch nur, um gelegentlich vim-Skripte profilen zu können.
Dazu kommen freilich noch diverse Laufzeitdateien, so dass die gesamte
Installation ca. 20 MB sind.
Aber: Ich benutze nie und nimmer einen anderen Editor als den vim, d.h. für
mich muss der vim wirklich alles können, was ein Editor jemals können muss.
Die Alternativen nvi und elvis habe ich schon probiert -- da fehlt mir immer
was. Sei es Syntax-Highlighting, Multilevel-Undo, Visual-Modus, oder was weiß
ich.
Hauke Laging
Muss man das auch begründen, oder kann man inzwischen auch hier
einfach alles so als Blödsinn bezeichnen? Konkret: Warum sollte eine
funktionierende Vorgehensweise "Blödsinn" sein, nur weil auch eine
andere funktioniert, auch wenn die andere in manchen Aspekten (die
in der konkreten Situation womöglich gar nicht zum Tragen kommen)
besser ist?
Wenn "Blödsinn" dasselbe ist wie "suboptimal", liegt offensichtlich
eine Sprachbehinderung vor. Aber manch einer will ja vor allem
rumlabern.
Hauke Laging
> Welchen Nutzen hat es denn, die PasswordAuthentification
> auszuschalten?
Ist die Frage ernst gemeint? Du dozierst hier über weltfremde Aspekte
wie einen Editorgrundkurs im Zusammenhang mit SSH und siehst keinen
relevanten Unterschied zwischen zwei SSH-Installationen, von denen
nur eine PasswordAuthentification erlaubt? Wirklich süß.
Aber klar, man kann ja sichere Passworte verwenden. So was wie
xZ62mznpAlFMri2nPWKZFVUwUaa1RIji. Das knackt keiner. Das hat zwar
keinen praktischen Belang, aber den nimmst Du für Deine Beiträge
wohl auch nicht in Anspruch.
> Klar, wenn er sich ein Exotensystem schaffen möchte, welches das
> einzige bleibt, mit dem er umgehen kann.
Lächerlich.
Wer ein Unix so installiert, dass vi als einziger Editor installiert
ist (was man bei normalen Distributionen vorsätzlich tun muss), der
soll dann nicht rumjammern, wenn ein Normalo-User mit dem System
nicht zurechtkommt. Ich halte es für wahrscheinlich, dass ein System
nur mit vi heutzutage im Rechtssinn ("mittlerer Art und Güte") als
mangelhaft angesehen würde.
Die "Exotensysteme", auf denen pico, nano oder joe installiert ist,
welchen Anteil der Rechner mit SSH-Accounts für normale User machen
die aus, 30%, 60%, 90%, 99%? Wenn man hier dummes Zeug redet, ist
man übrigens kein Exot.
> Möchte er aber auch an
> anderen Linux/Unix-Kisten nicht verzweifeln, gehört zum Einstieg
> auch ein kleiner Grundkurs in vi.
Und WAS hat nun ein "Grundkurs in vi" für jemanden, über dessen
vi-Kenntnisse Du exakt nichts weißt, mit einer SSH-Konfiguration zu
tun?
Unfassbar.
Hauke Laging
> Aber: Ich benutze nie und nimmer einen anderen Editor als den vim,
> d.h. für mich muss der vim wirklich alles können, was ein Editor
> jemals können muss.
Ach, so, das schließt natürlich wirksam aus, dass vim
ein "aufgeblasener Editor" ist.
Huch, es gibt auf einmal formal keine aufgeblasene Software mehr,
weil sich für jede irgendein Horst findet, der meint, dass alle
Aspekte dieser Software für ihn absolut lebensnotwendig seien? Egal,
seit wann wollen wir uns hier brauchbar äußern, nicht wahr?
--
http://www.hauke-laging.de/ideen/
Markus Wichmann
Wenn vim mir mit 4MB Größe genau das gleiche bieten würde wie nvi, würde
ich wohl auch eher letzteres nehmen. Tut es aber nicht. Oder kann nvi
seit neuestem vimscripts, Makros und Add-Ons wie den LaTeX-Suite?
Tschö,
Markus
--
Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart
terminals.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Bernd Hohmann
>>> sudo nano /etc/ssh/sshd_config und Eintrag
>>> „PasswordAuthentification=no“ setzen.
>>
>> Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
>> übrigens 'vi'.
>
> Muss man das auch begründen, oder kann man inzwischen auch hier
> einfach alles so als Blödsinn bezeichnen?
Ich glaube Martin ging es um das "sudo" um Root zu werden, was auf
Ubuntu hinweist.
sudo + nano + htop = Warmduscher
root + vi + top = Profi
:-)
Markus Wichmann
> Hauke Laging schrieb:
>
>>>> sudo nano /etc/ssh/sshd_config und Eintrag
>>>> „PasswordAuthentification=no“ setzen.
>>>
>>> Und nochmal Blödsinn, gleich doppelt und dreifach. Der Editor heißt
>>> übrigens 'vi'.
>>
>> Muss man das auch begründen, oder kann man inzwischen auch hier
>> einfach alles so als Blödsinn bezeichnen?
>
Man kann es auch als Honigkuchen bezeichnen. Aber generell einigt man
sich, glaube ich, auf eine Bedeutung, und das Ergebnis nennt man
Sprache...
Ansonsten steht es Martin frei, die sicherheitstechnischen
Errungenschaften der, sagen wir, letzten 10 Jahre, zu ignorieren.
Willkommen im Botnetz!
> Ich glaube Martin ging es um das "sudo" um Root zu werden, was auf
> Ubuntu hinweist.
>
> sudo + nano + htop = Warmduscher
> root + vi + top = Profi
>
top? Ein _richtiger_ Profi macht das mit ps. Oder gleich direkt mit nem
Shellskript, dass Daten aus /proc sammelt.
BTW: Ich hab meinen sudo-Konsum mittlerweile einigermaßen eingedämmt,
zugunsten von su. Oder einer root-Konsole.
Tauchte hier nicht vor ein paar Wochen einer auf, der unter Ubuntu
seinen eigenen Hauptuser aus der Admingruppe gelöscht hat? Fortan ging
nix mehr, weil es ja kein Root-PW gab.
> :-)
>
SCNR.
> Bernd
Realname [m]
Helmut Hullen
Du meintest am 01.01.10:
> Tauchte hier nicht vor ein paar Wochen einer auf, der unter Ubuntu
> seinen eigenen Hauptuser aus der Admingruppe gel�scht hat? Fortan
> ging nix mehr, weil es ja kein Root-PW gab.
Das l�sst sich leicht korrigieren ...
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Hauke Laging
> Hauke Laging <4q2...@hauke-laging.de> schrieb:
>
> [ Wirres ]
Dich nehme ich ernst, schon klar.
--
http://www.hauke-laging.de/ideen/
Realname [m]
Oliver Schad
> BTW: Ich hab meinen sudo-Konsum mittlerweile einigermaßen eingedämmt,
> zugunsten von su. Oder einer root-Konsole.
Ich nehme für jede Aufgabe ein eigenes Terminal.
Hauke Laging
Ich weiß gar nicht, welche dieser Zeilen aus dem Mund einer halben
Portion beeindruckender ist.
--
http://www.hauke-laging.de/ideen/
Christian Garbs
Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
> Martin Schmitz <ne...@rmz.ath.cx> wrote:
>> Bernd Hohmann wrote:
>>> vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach ~/.ssh/
>>> kopieren
>>> Schlüssel auf remote zufügen:
>>> cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
>> Blödsinn.
> Nein.
>> 'man ssh-copy-id'.
> DESCRIPTION
> ssh-copy-id is a script that uses ssh to log into a remote machine
> (presumably using a login password, so password authentication should
> be enabled, unless you've done some clever use of multiple identities)
>
> Und in dem Script findest sich dann folgende Zeile, die bis auf das "remote
> ausfuehren per ssh" und die "Quelle" fuer den public-key so ziemlich genau
> das tut, was Bernd geschrieben hat (abgesehen vom erstellen von ~/.ssh falls
> es das noch nicht gibt) ...
>
> { eval "$GET_ID" ; } | ssh ${1%:} "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1
Warum einen eventuell auf dem Zielsystem schon vorhandenen Public Key
überschreiben? ~/.ssh/id_dsa.pub als temporäre Datei zu benutzen ist
vielleicht nicht "Blödsinn", aber mindestens "suboptimal".
Das macht ssh-copy-id schon besser :-)
Gruß
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
Using encryption on the Internet is the equivalent of arranging an armored car
to deliver credit-card information from someone living in a cardboard box to
someone living on a park bench. -- Gene Spafford, quoted by Freedman/Mann
Realname [m]
> Realname [m] schrieb am Freitag 01 Januar 2010 20:02:
>
>> Hauke Laging <1q2...@hauke-laging.de> schrieb:
>>
>> [ *blub* ]
>>
>> Suchst du Aufmerksamkeit?
>
> Portion beeindruckender ist.
Hey, willst' mich anmachen, oder was?
Bernd Hohmann
> Realname [m] schrieb am Freitag 01 Januar 2010 20:02:
> [...]
> Ich weiß gar nicht, welche dieser Zeilen aus dem Mund einer halben
> Portion beeindruckender ist.
Bütte Hauke, setz einfach einen Filter und gut ist - ja? :-)
Realname [m]
> Hauke Laging schrieb:
>
>> Realname [m] schrieb am Freitag 01 Januar 2010 20:02:
>> Portion beeindruckender ist.
>
> Bï¿œtte Hauke, setz einfach einen Filter und gut ist - ja? :-)
Bï¿œtte nicht.
Dann bekommt er meine Mental-Verbalen-Aussetzer doch
gar nicht mehr mit...
Helmut Hullen
Du meintest am 01.01.10:
> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
Mindestens �hnlich bei Ubuntu; beim ersten Aufruf eines Programms, das
einen Editor braucht (bei meiner Installation war es "crontab"), werden
4 Editoren angeboten, mit Vor-Einstellung "nano".
Irgendwann schaue ich auch nach, ob das auch z.B. f�r "visudo" gilt und
wo das f�r "alle" (vermutlich: einige) Programme fest verankert wird.
Henning Paul
> Irgendwann schaue ich auch nach, ob das auch z.B. für "visudo" gilt und
> wo das für "alle" (vermutlich: einige) Programme fest verankert wird.
Schon mal was von den VISUAL- und EDITOR-Umgebungsvariablen gehört? Von
jemandem mit historischen Linuxkenntnissen hätte ich das jetzt erwartet...
Gruß
Henning (sehr zufrieden mit dem vim)
--
henning paul home: http://home.arcor.de/henning.paul
PM: henni...@gmx.de , ICQ: 111044613
Juergen Ilse
Christian Garbs <mi...@cgarbs.de> wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> Martin Schmitz <ne...@rmz.ath.cx> wrote:
>>> 'man ssh-copy-id'.
>
>> DESCRIPTION
>> ssh-copy-id is a script that uses ssh to log into a remote machine
>> (presumably using a login password, so password authentication should
>> be enabled, unless you've done some clever use of multiple identities)
>>
>> Und in dem Script findest sich dann folgende Zeile, die bis auf das "remote
>> ausfuehren per ssh" und die "Quelle" fuer den public-key so ziemlich genau
>> das tut, was Bernd geschrieben hat (abgesehen vom erstellen von ~/.ssh falls
>> es das noch nicht gibt) ...
>>
>> { eval "$GET_ID" ; } | ssh ${1%:} "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1
>
> Warum einen eventuell auf dem Zielsystem schon vorhandenen Public Key
> überschreiben?
Wo soll das passieren? Bei jeder bisher angesprochenen Loesung stand da
">>" in der Zeile, also "anhaengen" statt "ueberschreiben". Die oben
stehende Zeile ist uebrigens ein Zitat aus dem script ssh-copy-id, also
macht ssh-copy-id da gar nichts besser als die oben stehende Zeile: es
macht es *genauso* ...
Florian Diesch
> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
Der Standard ist bei Debianoiden eigentlich das �ber die Alternatives verwalteten
/usr/bin/editor, bei dem nano aber eine relativ hohe Priorit�t hat.
Florian
--
<http://www.florian-diesch.de/software/easygconf/>
Helmut Hullen
Du meintest am 01.01.10:
> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
Nachtrag f�r Ubuntu 9.10:
crontab hat gefragt; schl�gt "nano" vor
visudo benutzt (ungefragt) nano
vipw benutzt vi (was bei Ubuntu vermutlich "vim.tiny" ist)
Da steckt sicherlich ein System dahinter!
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Du meintest am 01.01.10:
>> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
> Nachtrag für Ubuntu 9.10:
> crontab hat gefragt; schlägt "nano" vor
> visudo benutzt (ungefragt) nano
> vipw benutzt vi (was bei Ubuntu vermutlich "vim.tiny" ist)
Haettest du es zuerst mit visudo probiert, waerst du vermutlich dabei
gefragt worden und dafuer bei den anderen beiden nicht ...
> Da steckt sicherlich ein System dahinter!
Natuerlich und eins, dass du offenbar noch nicht begriffen hast ...
Realname [m]
> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
Nein, denn dessen Bedienung weicht vom Standard ab.
Daher habe ich damit immer meine Mühe.
Oliver Schad
> Du meintest am 01.01.10:
>
>> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
>
> Mindestens ähnlich bei Ubuntu; beim ersten Aufruf eines Programms, das
> einen Editor braucht (bei meiner Installation war es "crontab"),
> werden 4 Editoren angeboten, mit Vor-Einstellung "nano".
>
> Irgendwann schaue ich auch nach, ob das auch z.B. für "visudo" gilt
> und wo das für "alle" (vermutlich: einige) Programme fest verankert
> wird.
In Unix-Systemen werden solche Sachen über Umgebungsvariablen gesteuert.
Falls keine Umgebungsvariable existiert, gibt es einen
programmabhängigen Standard, der normalerweise vi ist.
Oliver Schad
> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
> Für Kleinkram ist er gut zu verwenden und für das ernsthaftere
> Arbeiten nimmt man dann eh Emacs.
>
> Ralf ('vi' ist the core of every evil)
/me holt das Popcorn raus.
Christian Garbs
Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
> Christian Garbs <mi...@cgarbs.de> wrote:
>> Warum einen eventuell auf dem Zielsystem schon vorhandenen Public Key
>> überschreiben?
> Wo soll das passieren? Bei jeder bisher angesprochenen Loesung stand da
> ">>" in der Zeile, also "anhaengen" statt "ueberschreiben".
Ich zitiere aus <7pvcub...@mid.individual.net>:
| vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach ~/.ssh/
| kopieren
| Schlüssel auf remote zufügen:
|
| cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
~/.ssh/id_dsa.pub wird beim Kopieren plattgemacht.
Dass danach an ~/.ssh/authorized_keys mit >> angehängt wird, macht
eine eventuell vorher vorhandene id_dsa.pub nicht wieder lebendig.
Gruß
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
Murphy's Laws of Combat:
3. Don't look conspicuous, it draws fire.
Helmut Hullen
Du meintest am 02.01.10:
>> Nachtrag f�r Ubuntu 9.10:
>> crontab hat gefragt; schl�gt "nano" vor
>> visudo benutzt (ungefragt) nano
>> vipw benutzt vi (was bei Ubuntu vermutlich "vim.tiny" ist)
> Haettest du es zuerst mit visudo probiert, waerst du vermutlich dabei
> gefragt worden und dafuer bei den anderen beiden nicht ...
Aha!
Z�hlt so etwas zum Geheimwissen, �ber das nur die Kandidaten ab Level 5
verf�gen?
Denn so richtig intuitiv ist es nicht, mit "visudo" zu beginnen.
>> Da steckt sicherlich ein System dahinter!
> Natuerlich und eins, dass du offenbar noch nicht begriffen hast ...
So isses!
Besteht das System einzig aus "Gehe zu visudo. Gehe direkt dorthin.
..."? Dann k�nnte ich das System sicherlich lernen, aber nicht
begreifen.
Oliver Schad
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> Christian Garbs <mi...@cgarbs.de> wrote:
>
>>> Warum einen eventuell auf dem Zielsystem schon vorhandenen Public
>>> Key überschreiben?
>
>> Wo soll das passieren? Bei jeder bisher angesprochenen Loesung stand
>> da ">>" in der Zeile, also "anhaengen" statt "ueberschreiben".
>
> Ich zitiere aus <7pvcub...@mid.individual.net>:
>
> | vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach
> | ~/.ssh/ kopieren
> | Schlüssel auf remote zufügen:
> |
> | cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
>
> ~/.ssh/id_dsa.pub wird beim Kopieren plattgemacht.
Ich glaube, ich verstehe dich nicht. Mein "cat" löscht keine Dateien.
Deins schon?
Henning Paul
> Christian Garbs wrote:
>> | vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach
>> | ~/.ssh/ kopieren
[...]
>> ~/.ssh/id_dsa.pub wird beim Kopieren plattgemacht.
>
> Ich glaube, ich verstehe dich nicht. Mein "cat" löscht keine Dateien.
> Deins schon?
Das
>> | vom lokalen Rechner ~/.ssh/id_dsa.pub auf remote Rechner nach
>> | ~/.ssh/ kopieren
ist das Problem. Nicht cat.
Gruß
Henning
Henning Paul
> Hallo, Juergen,
>
> Du meintest am 02.01.10:
>
>>> Nachtrag für Ubuntu 9.10:
>>> crontab hat gefragt; schlägt "nano" vor
>>> visudo benutzt (ungefragt) nano
>>> vipw benutzt vi (was bei Ubuntu vermutlich "vim.tiny" ist)
>
>> Haettest du es zuerst mit visudo probiert, waerst du vermutlich dabei
>> gefragt worden und dafuer bei den anderen beiden nicht ...
>
> Aha!
> Zählt so etwas zum Geheimwissen, über das nur die Kandidaten ab Level 5
> verfügen?
Mal die Manpage konsultiert?
man visudo:
| ENVIRONMENT
| The following environment variables are used only if visudo was
| configured with the --with-env-editor option:
|
| VISUAL Invoked by visudo as the editor to use
|
| EDITOR Used by visudo if VISUAL is not set
HTH
Bernd Hohmann
> | cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
>
> ~/.ssh/id_dsa.pub wird beim Kopieren plattgemacht.
>
> Dass danach an ~/.ssh/authorized_keys mit >> angehängt wird, macht
> eine eventuell vorher vorhandene id_dsa.pub nicht wieder lebendig.
Das macht nichts.
Zum einen findet der Schlüsselvergleich nur über die authorized_keys
statt (dh. du kannst id_dsa.pub nach dem anhängen löschen) und zum
anderen kannst Du dir den Key aus der authorized_keys wieder herauskopieren.
Helmut Hullen
Du meintest am 02.01.10:
>>> nano ist BTW bei Debian der default-Editor, und das ist auch gut
>>> so.
>> Mindestens �hnlich bei Ubuntu; beim ersten Aufruf eines Programms,
>> das einen Editor braucht (bei meiner Installation war es "crontab"),
>> werden 4 Editoren angeboten, mit Vor-Einstellung "nano".
>>
>> Irgendwann schaue ich auch nach, ob das auch z.B. f�r "visudo" gilt
>> und wo das f�r "alle" (vermutlich: einige) Programme fest verankert
>> wird.
> In Unix-Systemen werden solche Sachen �ber Umgebungsvariablen
> gesteuert.
set | grep nano
ist leer,
set | grep mcedit
ist auch leer.
> Falls keine Umgebungsvariable existiert, gibt es einen
> programmabh�ngigen Standard, der normalerweise vi ist.
Aber anscheinend verstellt Ubuntu irgendwo diesen Standard. "visudo"
heisst ("eigentlich") deshalb so, weil es "vi" als Editor benutzt; wenn
ich einen anderen Editor benutzen will, dann m�sste ich z.B.
VISUAL=mcedit visudo
eingeben (Nebenbedingungen: "VISUAL" ist gesetzt, mcedit liegt im
Suchpfad). Macht Ubuntu das "irgendwo" auch so? Wenn ja: wo liegt diese
Einstellung?
"/root/bin/.selected_editor" enth�lt den Eintrag f�r "mcedit", den
jedoch weder "visudo" noch "vipw" ber�cksichtigt.
Und "visudo" benutzt (warum auch immer) nicht "vi", sondern "nano".
Sieht sehr wie ein Text-Adventure aus.
Florian Diesch
> Ralf D�blitz wrote:
>
>> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
>> F�r Kleinkram ist er gut zu verwenden und f�r das ernsthaftere
>> Arbeiten nimmt man dann eh Emacs.
>>
>> Ralf ('vi' ist the core of every evil)
>
> /me holt das Popcorn raus.
<http://en.opensuse.org/Popcorn>?
Florian
--
<http://www.florian-diesch.de/software/xxgamma/>
Helmut Hullen
Du meintest am 02.01.10:
>>> Haettest du es zuerst mit visudo probiert, waerst du vermutlich
>>> dabei gefragt worden und dafuer bei den anderen beiden nicht ...
>> Aha!
>> Z锟絟lt so etwas zum Geheimwissen, 锟絙er das nur die Kandidaten ab
>> Level 5 verf锟絞en?
> Mal die Manpage konsultiert?
Nein - nicht f锟絩 diese Runde ...
> man visudo:
> | ENVIRONMENT
> | The following environment variables are used only if visudo
> was | configured with the --with-env-editor option:
> |
> | VISUAL Invoked by visudo as the editor to use
> |
> | EDITOR Used by visudo if VISUAL is not set
Danke - kannte (und benutze) ich schon l锟絥ger.
Ubuntu 9.10: beide (m锟絞lichen) Umgebungsvariablen sind leer. Also m锟絪ste
"visudo" mit dem Editor "vi" arbeiten. Das Programm benutzt jedoch
"nano", nach Vor-Einstellung.
Auch "strace visudo" liefert nirgendwo einen Hinweis auf "nano". Kann
nat锟絩lich sein, dass dieser Editor vom Paketbauer fest einkompiliert
wurde, anstelle von "vi". Aber im Binary ist nirgendwo "nano" enthalten.
Wie also kommt "visudo" bei Ubuntu auf die Idee, "nano" zu benutzen?
Ray Banana
> Wie also kommt "visudo" bei Ubuntu auf die Idee, "nano" zu benutzen?
update-alternatives --display editor
editor - auto mode
link currently points to /bin/nano
ls -lart /etc/alternatives/editor
lrwxrwxrwx 1 root root 9 2009-10-29 18:59 /etc/alternatives/editor ->
/bin/nano
> "Ubuntu" - an African word, meaning "Slackware is too hard for me".
Na, wenigstens nimmst du dich selbst nicht ernst.
--
Time flies like an arrow, fruit flies like a Banana.
http://www.eternal-september.org
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
>> In Unix-Systemen werden solche Sachen über Umgebungsvariablen
>> gesteuert.
>
> set | grep nano
>
> ist leer,
>
> set | grep mcedit
>
> ist auch leer.
Was ergibt denn
set | grep -i editor
bei dir?
>> Falls keine Umgebungsvariable existiert, gibt es einen
>> programmabhängigen Standard, der normalerweise vi ist.
> Aber anscheinend verstellt Ubuntu irgendwo diesen Standard. "visudo"
> heisst ("eigentlich") deshalb so, weil es "vi" als Editor benutzt; wenn
> ich einen anderen Editor benutzen will, dann müsste ich z.B.
>
> VISUAL=mcedit visudo
>
> eingeben (Nebenbedingungen: "VISUAL" ist gesetzt, mcedit liegt im
> Suchpfad). Macht Ubuntu das "irgendwo" auch so? Wenn ja: wo liegt diese
> Einstellung?
Vermutlich im Environment (dass du anscheinend nicht mit tauglichen
Mitteln durchsuchst). Ausserdem solltest du ggfs. darauf achten, dass
man solche Environment-Variablen auch "exportiert", damit sie auch im
Environment von Child-Prozessen auftauchen ...
> "/root/bin/.selected_editor" enthält den Eintrag für "mcedit", den
> jedoch weder "visudo" noch "vipw" berücksichtigt.
>
> Und "visudo" benutzt (warum auch immer) nicht "vi", sondern "nano".
>
> Sieht sehr wie ein Text-Adventure aus.
Sieht eher nach "denn sie wissen nicht was sie tun" aus (und damit meine
ich jetzt nicht die Entwickler der Distribution, sondern in deinem Fall
den Anwender ...).
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Du meintest am 02.01.10:
>>>> Haettest du es zuerst mit visudo probiert, waerst du vermutlich
>>>> dabei gefragt worden und dafuer bei den anderen beiden nicht ...
>>> Aha!
>>> Zählt so etwas zum Geheimwissen, über das nur die Kandidaten ab
>>> Level 5 verfügen?
Nein. Es ist schlicht so, dass das erste Programm das /usr/bin/editor zu
verwenden versucht, diese Abfrage ausloest, deren Beantwortung dann das
umsetzen eines Softlinks bewirkt, so dass nachfolgende Aufrufe dann den
gewaehlten Editor aufrufen. Ich dachte mein Hinweis haette fuer die nahe-
liegende Schlussfolgerung gereicht, dass das erste entsprechende Programm
die Einstellung umsetzt, egal, ob das nun "vipw", "visudo" oder "crontab"
ist, aber da habe ich mich wohl (zumindest bei deiner Person) wohl geirrt ...
>> | ENVIRONMENT
>> | The following environment variables are used only if visudo
>> was | configured with the --with-env-editor option:
>> |
>> | VISUAL Invoked by visudo as the editor to use
>> |
>> | EDITOR Used by visudo if VISUAL is not set
>
> Danke - kannte (und benutze) ich schon länger.
>
> Ubuntu 9.10: beide (möglichen) Umgebungsvariablen sind leer. Also müsste
> "visudo" mit dem Editor "vi" arbeiten. Das Programm benutzt jedoch
> "nano", nach Vor-Einstellung.
> Auch "strace visudo" liefert nirgendwo einen Hinweis auf "nano". Kann
> natürlich sein, dass dieser Editor vom Paketbauer fest einkompiliert
> wurde, anstelle von "vi". Aber im Binary ist nirgendwo "nano" enthalten.
> Wie also kommt "visudo" bei Ubuntu auf die Idee, "nano" zu benutzen?
Warum auch nicht naheliegende Methoden probieren, wie im stracelog nach
"exec" statt nach "nano" zu suchen (weil nano auch ueber einen link auf-
gerufen werden koennte) und dabei strace auch mit der Option "-f" verwen-
den, weil der Editor-Aufruf ja vermutlich in einem subprozess erfolgt,
damit visudo anschliessend weiter abgearbeitet werden kann ...
Alternativ (und wesentlich weniger aufwendig) koennte man ja auch mal
nach dem "systemspezifischen Default" fuer den Editor suchen:
root@talaxia:~# strings /usr/sbin/visudo | grep bin
/bin/sh
/usr/sbin/sendmail
/usr/bin/editor
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
/bin/mv
Das sieht doch sehr danach aus, dass /usr/bin/editor der "systemspezifische
Default" fuer den Editor ist, oder etwa nicht? Eine entsprechende Untersu-
chung der Programme "/usr/bin/crontab" und "/usr/sbin/vipw§ ueberlasse ich
dir selbst ...
Ach ja, falls dir auch das unbekannt sein sollte: Eine Default-Einstellung
fuer das Environment, die global fuer das System gilt (solange sie nicht
ausdruecklich ueberschrieben wird) kann man uebrigens (auch unabhaengig
von der login-shell) in /etc/environment setzen, also z.B.
root@talaxia:~# grep EDITOR /etc/environment
EDITOR=/usr/bin/vi
root@talaxia:~#
Die Transferleistung, das auf dine Wuensche anzupassen, ueberlasse ich
auch dir (in der Hoffnung, dich damit nicht zu ueberfordern).
Helmut Hullen
Du meintest am 02.01.10:
>> Wie also kommt "visudo" bei Ubuntu auf die Idee, "nano" zu benutzen?
> update-alternatives --display editor
> editor - auto mode
> link currently points to /bin/nano
> ls -lart /etc/alternatives/editor
> lrwxrwxrwx 1 root root 9 2009-10-29 18:59 /etc/alternatives/editor ->
> /bin/nano
Steht hier auch so.
Wieso werde ich bei "crontab" noch mal extra gefragt, wieso kann ich da
einen anderen Editor einstellen? (Zur Erinnerung: vorgeschlagen wurde
"nano").
Wieso gilt der unter "alternatives" eingestellte Editor f�r "visudo",
aber nicht f�r "vipw"?
Viele Gruesse
Helmut
Helmut Hullen
Du meintest am 02.01.10:
>>>>> Haettest du es zuerst mit visudo probiert, waerst du vermutlich
>>>>> dabei gefragt worden und dafuer bei den anderen beiden nicht ...
>>>> Aha!
>>>> Z�hlt so etwas zum Geheimwissen, �ber das nur die Kandidaten ab
>>>> Level 5 verf�gen?
> Nein. Es ist schlicht so, dass das erste Programm das /usr/bin/editor
> zu verwenden versucht, diese Abfrage ausloest, deren Beantwortung
> dann das umsetzen eines Softlinks bewirkt, so dass nachfolgende
> Aufrufe dann den gewaehlten Editor aufrufen.
Trifft f�r meine Installation nicht zu. Ab Werk vor-eingestellt ist bei
"alternatives" "nano". Aber dieser Voreinstellung wird nicht f�r "vipw"
benutzt.
Und ich konnte die Vor-Einstellung f�r "crontab" �ndern, nicht jedoch
f�r "visudo".
> Ich dachte mein Hinweis
> haette fuer die nahe- liegende Schlussfolgerung gereicht, dass das
> erste entsprechende Programm die Einstellung umsetzt, egal, ob das
> nun "vipw", "visudo" oder "crontab" ist, aber da habe ich mich wohl
> (zumindest bei deiner Person) wohl geirrt ...
Nein - Du hast Dich beim vermuteten Mechanismus geirrt.
>> Auch "strace visudo" liefert nirgendwo einen Hinweis auf "nano".
>> Kann nat�rlich sein, dass dieser Editor vom Paketbauer fest
>> einkompiliert wurde, anstelle von "vi". Aber im Binary ist nirgendwo
>> "nano" enthalten. Wie also kommt "visudo" bei Ubuntu auf die Idee,
>> "nano" zu benutzen?
> Alternativ (und wesentlich weniger
> aufwendig) koennte man ja auch mal nach dem "systemspezifischen
> Default" fuer den Editor suchen:
> root@talaxia:~# strings /usr/sbin/visudo | grep bin
> /bin/sh
> /usr/sbin/sendmail
> /usr/bin/editor
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11
> R6/bin /bin/mv
> Das sieht doch sehr danach aus, dass /usr/bin/editor der
> "systemspezifische Default" fuer den Editor ist, oder etwa nicht?
So isses - danke!
Ist bei Ubuntu ein Symlink nach "/etc/alternatives/editor".
> Eine entsprechende Untersu- chung der Programme "/usr/bin/crontab"
> und "/usr/sbin/vipw" ueberlasse ich dir selbst ...
In beiden F�llen: kein Aufruf von "/usr/bin/editor".
Innerhalb von "vipw": ein Aufruf von ".../vi" (Suche in etlichen
Verzeichnissen).
> Ach ja, falls dir auch das unbekannt sein sollte: Eine
> Default-Einstellung fuer das Environment, die global fuer das System
> gilt (solange sie nicht ausdruecklich ueberschrieben wird) kann man
> uebrigens (auch unabhaengig von der login-shell) in /etc/environment
> setzen, also z.B.
> root@talaxia:~# grep EDITOR /etc/environment
> EDITOR=/usr/bin/vi
> root@talaxia:~#
Ist mir bekannt - danke.
Aber (s.o.) bei "visudo" und "vipw" arbeite ich mit den Vor-
Einstellungen von Ubuntu.
> Die Transferleistung, das auf dine Wuensche anzupassen, ueberlasse
> ich auch dir (in der Hoffnung, dich damit nicht zu ueberfordern).
Danke f�r Deine �berbordende Hilfsbereitschaft und F�rsorge!
Helmut Hullen
Du meintest am 02.01.10:
>>> In Unix-Systemen werden solche Sachen �ber Umgebungsvariablen
>>> gesteuert.
>>
>> set | grep nano
>>
>> ist leer,
>>
>> set | grep mcedit
>>
>> ist auch leer.
> Was ergibt denn
> set | grep -i editor
> bei dir?
Auch leer.
>>> Falls keine Umgebungsvariable existiert, gibt es einen
>>> programmabh�ngigen Standard, der normalerweise vi ist.
>> Aber anscheinend verstellt Ubuntu irgendwo diesen Standard. "visudo"
>> heisst ("eigentlich") deshalb so, weil es "vi" als Editor benutzt;
>> wenn ich einen anderen Editor benutzen will, dann m�sste ich z.B.
>>
>> VISUAL=mcedit visudo
>>
>> eingeben (Nebenbedingungen: "VISUAL" ist gesetzt, mcedit liegt im
>> Suchpfad). Macht Ubuntu das "irgendwo" auch so? Wenn ja: wo liegt
>> diese Einstellung?
> Vermutlich im Environment (dass du anscheinend nicht mit tauglichen
> Mitteln durchsuchst).
Aha.
Mit meinen Werkzeugen wird weder "nano" noch "mcedit" angezeigt.
Vielleicht ist da ja auch nichts.
> Ausserdem solltest du ggfs. darauf achten, dass
> man solche Environment-Variablen auch "exportiert", damit sie auch im
> Environment von Child-Prozessen auftauchen ...
Sorry - ist noch nicht mein Bier. Noch arbeite ich (ausser bei
"crontab") mit den Vor-Einstellungen von Ubuntu.
>> "/root/bin/.selected_editor" enth�lt den Eintrag f�r "mcedit", den
>> jedoch weder "visudo" noch "vipw" ber�cksichtigt.
>>
>> Und "visudo" benutzt (warum auch immer) nicht "vi", sondern "nano".
>>
>> Sieht sehr wie ein Text-Adventure aus.
> Sieht eher nach "denn sie wissen nicht was sie tun" aus (und damit
> meine ich jetzt nicht die Entwickler der Distribution, sondern in
> deinem Fall den Anwender ...).
Erz�hl mal mehr: wo und wie sollte ich weiterforschen?
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Wieso gilt der unter "alternatives" eingestellte Editor für "visudo",
> aber nicht für "vipw"?
Da ich fuer so etwas ohnehin "nvi" oder notfalls auch einen "klassischen
vi" bevorzuge, ist mir das noch gar nicht aufgefallen ... Das wird vermut-
lich daran liegen, dass niemand den "Default" dort von "vi" auf etwas an-
deres wie z.B. /usr/bin/editor umgesetzt hat.
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Du meintest am 02.01.10:
>> Nein. Es ist schlicht so, dass das erste Programm das /usr/bin/editor
>> zu verwenden versucht, diese Abfrage ausloest, deren Beantwortung
>> dann das umsetzen eines Softlinks bewirkt, so dass nachfolgende
>> Aufrufe dann den gewaehlten Editor aufrufen.
> Trifft für meine Installation nicht zu. Ab Werk vor-eingestellt ist bei
> "alternatives" "nano". Aber dieser Voreinstellung wird nicht für "vipw"
> benutzt.
Wohin zeigt der link /usr/bin/editor? Wenn du nach der von mir vorge-
schlagenen Methode recherchiert haettest (einfach in den binarys nach
Strings suchen, die Pfadangaben zu den aufgerufenen Editoren sein koenn-
ten), dann haettest du festgestellt, dass (entgegen meiner ursprueng-
lichen Vermutung) bei visudo /usr/bin/editor, bei crontab jedoch
/usr/bin/sensible-editor verwendet wird. Die man-page zu "sensible-editor"
verraet dann, wie man die Einstellung des davon aufgerufenen Editors
aendern kann.
> Und ich konnte die Vor-Einstellung für "crontab" ändern, nicht jedoch
> für "visudo".
Das kannst du, indem du das Environment passend setzt. Bei manchen
Distributionen (so auch bei Ubuntu) sind (IMHO leider) auch andere
Mechanismen implementiert, um bei nicht gesetztem Environment den
passenden Editor auszuwaehlen, statt einfach den (auf fast allen
anderen unixoiden Systemen ueblichen) Default /usr/bin/vi oder (falls
der nicht vorhanden ist) /bin/ed zu verwenden.
>> Ich dachte mein Hinweis
>> haette fuer die nahe- liegende Schlussfolgerung gereicht, dass das
>> erste entsprechende Programm die Einstellung umsetzt, egal, ob das
>> nun "vipw", "visudo" oder "crontab" ist, aber da habe ich mich wohl
>> (zumindest bei deiner Person) wohl geirrt ...
In diesem Punkt hatte ich mich geirrt, weil ich (mangels Bedarf: ich
habe einfach bei der Installation des Systems vor vielen Jahren die
passende Einstellung in /etc/environment eingetragen) das nicht wirk-
lich bei allen binarys untersucht habe ...
> Nein - Du hast Dich beim vermuteten Mechanismus geirrt.
Ich habe mich in dem Punkt geirrt, dass (leider) nicht alle Programme
den selben Mechanismus verwenden. Ich habe mich nicht geirrt, was die
triviale Einstellung betrifft, die alle 3 Programme dazu bringt, einen
bestimmten Editor zu verwenden (passendes setzen des Environments).
Martin Schmitz
> In Unix-Systemen werden solche Sachen über Umgebungsvariablen
> gesteuert. Falls keine Umgebungsvariable existiert, gibt es einen
> programmabhängigen Standard, der normalerweise vi ist.
Nicht so bei Debian (ja, auch, aber) da gibt's /etc/alternatives
Martin
Helmut Hullen
Du meintest am 02.01.10:
>> Wieso gilt der unter "alternatives" eingestellte Editor f�r
>> "visudo", aber nicht f�r "vipw"?
> Da ich fuer so etwas ohnehin "nvi" oder notfalls auch einen
> "klassischen vi" bevorzuge, ist mir das noch gar nicht aufgefallen
> ... Das wird vermut- lich daran liegen, dass niemand den "Default"
> dort von "vi" auf etwas an- deres wie z.B. /usr/bin/editor umgesetzt
> hat.
Ist ja eigentlich auch nicht n�tig.
Wenn "ganz oben" "VISUAL=/usr/bin/wasweissich" gesetzt (und per
"profile" o.�. exportiert) wird, dann ist weder "/usr/bin/editor" noch
"/etc/alternatives/editor" n�tig.
Sieht eher so aus, als ob Debian/Ubuntu das f�nfeckige Rad erfunden hat.
Helmut Hullen
Du meintest am 02.01.10:
> Wohin zeigt der link /usr/bin/editor?
Hatte ich schon mal erw�hnt: nach "/etc/alternatives/editor", was ab
Werk ein Link nach "nano" ist.
> Wenn du nach der von mir vorge-
> schlagenen Methode recherchiert haettest (einfach in den binarys nach
> Strings suchen, die Pfadangaben zu den aufgerufenen Editoren sein
> koenn- ten), dann haettest du festgestellt, dass (entgegen meiner
> ursprueng- lichen Vermutung) bei visudo /usr/bin/editor, bei crontab
> jedoch /usr/bin/sensible-editor verwendet wird.
Wobei "sensible-editor" zu ~/.selected-editor f�hrt, also je nach User
verschieden sein kann.
Soweit war Linux schon mal - damals wurde so etwas am ehesten per
"profile" und/oder "/etc/profile.d/xyz.sh" (f�r alle) sowie "~./profile"
(individuell) gel�st.
Wenn ich den Wirrwarr richtig entflechte, dann ist der ganz grosse
Unterschied das Skript "/usr/bin/select-editor", das (pro User) eine Art
Oberfl�che f�r die Wahl des Lieblings-Editors liefert. Der Rest:
Debianismus - fr�her reichten Umgebungsvariable.
Und das Konzept ist noch nicht mal vollst�ndig umgesetzt - siehe meine
Erfahrungen mit "crontab" (benutzt User-Definition), "visudo" (benutzt
Definition f�r alle) und "vipw" (benutzt nicht den Debianismus, sondern
das klassische VISUAL (oder EDITOR)).
>> Und ich konnte die Vor-Einstellung f�r "crontab" �ndern, nicht
>> jedoch f�r "visudo".
> Das kannst du, indem du das Environment passend setzt.
Aber dann brauche ich das ganze "selected-editor"-Geraffel nicht.
> Bei manchen Distributionen (so auch bei Ubuntu) sind (IMHO leider)
> auch andere Mechanismen implementiert, um bei nicht gesetztem
> Environment den passenden Editor auszuwaehlen, statt einfach den (auf
> fast allen anderen unixoiden Systemen ueblichen) Default /usr/bin/vi
> oder (falls der nicht vorhanden ist) /bin/ed zu verwenden.
Sag ich doch!
> Ich habe mich in dem Punkt geirrt, dass (leider) nicht alle Programme
> den selben Mechanismus verwenden. Ich habe mich nicht geirrt, was die
> triviale Einstellung betrifft, die alle 3 Programme dazu bringt,
> einen bestimmten Editor zu verwenden (passendes setzen des
> Environments).
Aber genau dieser klassische Mechanismus ist bei Ubuntu teilweise
ausgehebelt.
Helmut Hullen
Du meintest am 02.01.10:
>> In Unix-Systemen werden solche Sachen �ber Umgebungsvariablen
>> gesteuert. Falls keine Umgebungsvariable existiert, gibt es einen
>> programmabh�ngigen Standard, der normalerweise vi ist.
> Nicht so bei Debian (ja, auch, aber) da gibt's /etc/alternatives
Nachdem viele Jahre mit "EDITOR" und "VISUAL" problemlos gearbeitet
wurde.
Oliver Schad
> Du meintest am 02.01.10:
>>> Irgendwann schaue ich auch nach, ob das auch z.B. für "visudo" gilt
>>> und wo das für "alle" (vermutlich: einige) Programme fest verankert
>>> wird.
>
>> In Unix-Systemen werden solche Sachen über Umgebungsvariablen
>> gesteuert.
>
> set | grep nano
>
> ist leer,
>
> set | grep mcedit
>
> ist auch leer.
Die Variable heißt EDITOR. Ist sie leer, wird ein programmabhängiger
Standard geladen. Dafür kann man einfach mal
$ strings $(which crontab) | grep bin
machen und schauen, was rauskommt.
> Und "visudo" benutzt (warum auch immer) nicht "vi", sondern "nano".
Auch da kann man grep machen, um rauszufinden, was hartkodiert ist.
Oliver Schad
> root@talaxia:~# strings /usr/sbin/visudo | grep bin
> /bin/sh
> /usr/sbin/sendmail
> /usr/bin/editor
>
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
> /bin/mv
Da ist jemand auf die gleiche Idee gekommen.
> Das sieht doch sehr danach aus, dass /usr/bin/editor der
> "systemspezifische Default" fuer den Editor ist, oder etwa nicht?
Ja richtig, das ist systemabhängig. Bei mir ist das /bin/vi
Christian Garbs
Bernd Hohmann <bernd.hohma...@freihaendler.com> wrote:
> Christian Garbs schrieb:
Der Einfachheit beschränke ich das mal auf den relevanten Teil:
>> ~/.ssh/id_dsa.pub wird beim Kopieren plattgemacht.
> Das macht nichts.
Doch :)
Wenn auf dem Zielrechner bereits ein Key existiert und ich
vom Quellrechner ~/.ssh/id_dsa.pub nach ~/.ssh auf dem Zielrechner
kopiere, dann ist der vorherige Public Key weg.
Das sollte man nur beachten, um mehr geht es mir nicht.
Gruß
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
Fatal Error # 0x155 : Windows not found: (C)heer, (P)arty, (D)ance?
Helmut Hullen
Du meintest am 02.01.10:
>> root@talaxia:~# strings /usr/sbin/visudo | grep bin
>> /usr/bin/editor
> Da ist jemand auf die gleiche Idee gekommen.
>> Das sieht doch sehr danach aus, dass /usr/bin/editor der
>> "systemspezifische Default" fuer den Editor ist, oder etwa nicht?
> Ja richtig, das ist systemabh�ngig. Bei mir ist das /bin/vi
Ubuntu (und vielleicht auch Debian): "/usr/bin/editor" ist ein Symlink
auf "/etc/alternatives/editor", was bei Ubuntu nach Vor-Einstellung ein
Link nach "/bin/nano" ist. Gilt systemweit, kann nicht f�r den einzelnen
User umdefiniert werden. Und etliche Distributionen kennen "/usr/bin/
editor" noch nicht ...
Wenn ich das individuell einstellen will:
VISUAL=mcedit visudo
funktioniert immer noch. Warum einfach, wenn's auch umst�ndlich geht ...
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Wenn ich den Wirrwarr richtig entflechte, dann ist der ganz grosse
> Unterschied das Skript "/usr/bin/select-editor", das (pro User) eine Art
> Oberfläche für die Wahl des Lieblings-Editors liefert. Der Rest:
> Debianismus - früher reichten Umgebungsvariable.
"/usr/bin/select-editor" ist kein script sondern ein compiliertes binary
(jedenfalls bei mir). Und ja, ich stimme dir zu, dass das ganze Zeugs
voellig daneben und hochgradig ueberfluessig ist: es waere besser gewesen,
$VISUAL und/odfer §EDITOR per Default passend zu setzen (z.B. in der Datei
/etc/environment oder durch einlesen einer weiteren Konfigurationsdatei,
was dann natuerlich dokumentiert sein sollte).
> Und das Konzept ist noch nicht mal vollständig umgesetzt - siehe meine
> Erfahrungen mit "crontab" (benutzt User-Definition), "visudo" (benutzt
> Definition für alle) und "vipw" (benutzt nicht den Debianismus, sondern
> das klassische VISUAL (oder EDITOR)).
Das "klassische VISUAL (oder EDITOR)" funktioniert bei all diesen Programmen,
also waere das fuer jemanden der weiss was er tut die Methode der Wahl (die
nebenbei auch noch die "Debian-Sonderlocken" disabled und damit einen Gross-
teil deiner Kritik ueberfluessig gemacht haette).
>> Ich habe mich in dem Punkt geirrt, dass (leider) nicht alle Programme
>> den selben Mechanismus verwenden. Ich habe mich nicht geirrt, was die
>> triviale Einstellung betrifft, die alle 3 Programme dazu bringt,
>> einen bestimmten Editor zu verwenden (passendes setzen des
>> Environments).
> Aber genau dieser klassische Mechanismus ist bei Ubuntu teilweise
> ausgehebelt.
Keineswegs. Das einzige was dort "ausgehenelt" ist, ist die Wahl des zu
verwendenden Editors oder Pagers, falls es keinerlei Vorgaben dazu gibt.
Der klassische Mechanismus sieht vor, die entsprechenden Variablen gemaess
der eigenen Vorlieben zu setzen, und in dem Fall reagiert Debian oder
Ubuntu genau gemaess diesem "klassischen Mechanismus".
Florian Diesch
> Florian Diesch <die...@spamfence.net> schrieb:
>> Ralf D�blitz <doeb...@doeblitz.net> writes:
>>
>>
>>> nano ist BTW bei Debian der default-Editor, und das ist auch gut so.
>>
>> Der Standard ist bei Debianoiden eigentlich das �ber die Alternatives verwalteten
>> /usr/bin/editor, bei dem nano aber eine relativ hohe Priorit�t hat.
>
> Und nano ist selbst bei einem sehr nackten Debian mit dabei. Wenn man
> nat�rlich einen vim mit X11 installiert und nano explizit abw�hlt (nie
> ausprobiert), dann ...
Ein "vollst�ndiger" vim (d.h. nicht vim-tiny) hat AFAIR h�here Priorit�t
als nano, d.h. es reicht, sowas zu installieren, damit nano nicht mehr
Standard ist. nano ist aber nat�rlich der Standard-Standard-Editor ;-)
Florian
--
<http://www.florian-diesch.de/software/pdfrecycle/>
Marc Haber
>Du meintest am 02.01.10:
>
>Nachdem viele Jahre mit "EDITOR" und "VISUAL" problemlos gearbeitet
>wurde.
Das funktioniert natürlich auch und hat ggf. Vorrang vor dem
Debian-Mechanismus.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Marc Haber
>Wieso werde ich bei "crontab" noch mal extra gefragt, wieso kann ich da
>einen anderen Editor einstellen?
Wie genau sieht diese Frage aus? Laut manpage nimmt crontab
/usr/bin/editor, wenn weder VISUAL noch EDITOR gesetzt sind.
/usr/bin/editor ist ein symlink auf den per alternatives gesetzten
editor.
>Wieso gilt der unter "alternatives" eingestellte Editor für "visudo",
visudo ist bei der Auswahl des Editors extrem flexibel, neben dem
VISUAL/EDITOR-Mechanismus kann man den Editor auch noch direkt in der
/etc/sudoers einstellen und man kann zur compile-Zeit einen
Defaultwert vorgeben. Und zusätzlich kann man alle dieser Mechanismen
noch per /etc/sudoers abschalten, um privilege escalation zu
verhindern.
>aber nicht für "vipw"?
Dummes Programm, kann nur VISUAL/EDITOR und nimmt in deren Abwesenheit
hartcodiert immer vi?
Marc Haber
>Sieht eher so aus, als ob Debian/Ubuntu das fünfeckige Rad erfunden hat.
Ich sehe nicht, wo Dein Problem damit ist, einen unverändert weiter
verfügbaren Standardmechanismus durch einen darunterliegenden
Mechanismus, der systemweite Defaults ohne Herumpfuschen in
Userkonfigurationsdateien ermöglicht, zu ergänzen.
Marc Haber
Helmut Hullen
Du meintest am 03.01.10:
>>> Nicht so bei Debian (ja, auch, aber) da gibt's /etc/alternatives
>> Nachdem viele Jahre mit "EDITOR" und "VISUAL" problemlos gearbeitet
>> wurde.
> Das funktioniert nat�rlich auch und hat ggf. Vorrang vor dem
> Debian-Mechanismus.
Welchen Nutzen hat denn dann der Debian-Mechanismus (ausser "man hat was
Eigenes")?
Insbesondere "/etc/alternatives/editor" gilt "f�r alle" und muss
folglich am ehesten durch "mein Lieblings-Editor" �bersteuert werden.
Helmut Hullen
Du meintest am 03.01.10:
>> Sieht eher so aus, als ob Debian/Ubuntu das f�nfeckige Rad erfunden
>> hat.
> Ich sehe nicht, wo Dein Problem damit ist, einen unver�ndert weiter
> verf�gbaren Standardmechanismus durch einen darunterliegenden
> Mechanismus, der systemweite Defaults ohne Herumpfuschen in
> Userkonfigurationsdateien erm�glicht, zu erg�nzen.
"EDITOR" systemweit: "/etc/profile" oder (z.B.) "/etc/profile.d/
editor.sh". Spezielle Userw�nsche: "/.profile".
Wo ist der Vorteil des Debian-Mechanismus?
Oliver Schad
> Bernd Hohmann <bernd.hohma...@freihaendler.com> wrote:
>>Keygen: ssh-keygen -t dsa
>
> Warum dsa?
Warum nicht?
Helmut Hullen
Du meintest am 03.01.10:
>> Wieso gilt der unter "alternatives" eingestellte Editor f�r
>> "visudo",
> visudo ist bei der Auswahl des Editors extrem flexibel, neben dem
> VISUAL/EDITOR-Mechanismus kann man den Editor auch noch direkt in der
> /etc/sudoers einstellen
Ubuntu-Vor-Einstellung: nichts dergleichen
> und man kann zur compile-Zeit einen Defaultwert vorgeben.
Ubuntu 9.10: ist bereits kompiliert. Mit Vor-Einstellung "/usr/bin/
editor". Sieht nach einer Speziall�sung (L�sung?) f�r Ubuntu und/oder
Debian aus.
> Und zus�tzlich kann man alle dieser Mechanismen
> noch per /etc/sudoers abschalten, um privilege escalation zu
> verhindern.
Ubuntu-Vor-Einstellung: nichts dergleichen
>> aber nicht f�r "vipw"?
> Dummes Programm, kann nur VISUAL/EDITOR und nimmt in deren
> Abwesenheit hartcodiert immer vi?
Aha - ein Programm, das sich "klassisch" verh�lt, ist dumm?
Hans Christian Andersen, "Des Kaisers neue Kleider":
"In der gro�en Stadt, in der er wohnte, ging es sehr munter her. An
jedem Tag kamen viele Fremde an, und eines Tages kamen auch zwei
Betr�ger, die gaben sich f�r Weber aus und sagten, da� sie das sch�nste
Zeug, was man sich denken k�nne, zu weben verstanden. Die Farben und das
Muster seien nicht allein ungew�hnlich sch�n, sondern die Kleider, die
von dem Zeuge gen�ht w�rden, sollten die wunderbare Eigenschaft
besitzen, da� sie f�r jeden Menschen unsichtbar seien, der nicht f�r
sein Amt tauge oder der unverzeihlich dumm sei."
Ray Banana
>>> Sieht eher so aus, als ob Debian/Ubuntu das fï¿œnfeckige Rad erfunden
>>> hat.
>> Ich sehe nicht, wo Dein Problem damit ist, einen unverï¿œndert weiter
>> verfï¿œgbaren Standardmechanismus durch einen darunterliegenden
>> Mechanismus, der systemweite Defaults ohne Herumpfuschen in
>> Userkonfigurationsdateien ermï¿œglicht, zu ergï¿œnzen.
> "EDITOR" systemweit: "/etc/profile" oder (z.B.) "/etc/profile.d/
> editor.sh". Spezielle Userwï¿œnsche: "/.profile".
> Wo ist der Vorteil des Debian-Mechanismus?
Er ist universell:
update-alternatives --display java
java - Status ist auto.
Link verweist zur Zeit auf /usr/lib/jvm/java-6-openjdk/jre/bin/java
/usr/bin/gij-4.3 - Prioritï¿œt 43
/usr/lib/jvm/java-gcj/jre/bin/java - Prioritï¿œt 1042
/usr/lib/jvm/java-6-openjdk/jre/bin/java - Prioritï¿œt 1061
Slave java.1.gz: /usr/lib/jvm/java-6-openjdk/jre/man/man1/java.1.gz
Gegenwￜrtig ￜbesteￜ Version ist
/usr/lib/jvm/java-6-openjdk/jre/bin/java.
update-alternatives --display cc
cc - Status ist auto.
Link verweist zur Zeit auf /usr/bin/gcc
/usr/bin/gcc - Prioritï¿œt 20
Gegenwￜrtig ￜbesteￜ Version ist /usr/bin/gcc.
--
Time flies like an arrow, fruit flies like a Banana.
http://www.eternal-september.org
Joerg Mertens
> Welchen Nutzen hat denn dann der Debian-Mechanismus (ausser "man hat was
> Eigenes")?
Der ist für Programme, die mit gleichem Namen aufgerufen werden
können. Wenn du z.B. vim, nvi und elvis installierst, können nicht alle
Pakete einen symbolischen Link "vi" in /usr/bin ablegen. Über den
Alternatives-Mechanismus kannst du aber einstellen, welcher Editor bei
Eingabe von "vi" gestartet werden soll, ohne im /usr-Verzeichnis etwas
ändern zu müssen.
> Insbesondere "/etc/alternatives/editor" gilt "für alle" und muss
> folglich am ehesten durch "mein Lieblings-Editor" übersteuert werden.
Andererseits: wenn man die "Alternatives" schon mal hat, ist es auch
kein großer Aufwand, eine Konfiguration für "editor" zu erstellen. Stört
ja nicht, ist von den Umgebungsvariablen unabhängig und lässt sich
einfach Skripten. Vielleicht gibt es sogar Leute, die ihren Editor gerne
mit "editor" aufrufen, weil sie sich "vi" nicht merken können.
Gruß
Jörg
Helmut Hullen
Du meintest am 03.01.10:
>> Wo ist der Vorteil des Debian-Mechanismus?
> Er ist universell:
> update-alternatives --display java
> java - Status ist auto.
Gilt f�r alle Benutzer des Systems. Wenn ich als Eigenbr�tler was
anderes haben will, dann muss ich immer noch diese systemweite Vor-
Einstellung �berlisten. Wo ist der Vorteil gegen�ber den Umgebungs-
Variablen?
Warum nicht mehr "profile" (systemweit und per User), sondern
"alternatives" (nur systemweit)?
Bernd Hohmann
>> Wo ist der Vorteil des Debian-Mechanismus?
>
> Er ist universell:
Interessant... ist mir das bislang noch nicht über den Weg gelaufen.
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
Ralph Angenendt
> Gilt fï¿œr alle Benutzer des Systems. Wenn ich als Eigenbrï¿œtler was
>
> Warum nicht mehr "profile" (systemweit und per User), sondern
> "alternatives" (nur systemweit)?
Nur um dich zu ï¿œrgern.
Ralph
--
E.E. CUMMINGS BELIEVES IN CAPSLOCK
-- @amandapalmer
Nicht schreiben kï¿œnnen: http://lestighaniker.de/
Henning Paul
> Ray Banana schrieb:
>
>>> Wo ist der Vorteil des Debian-Mechanismus?
>>
>> Er ist universell:
>
> Interessant... ist mir das bislang noch nicht über den Weg gelaufen.
Mir schon, aus irgend einem Grund zeigte gcc auf einer Lenny-
Defaultinstallation auf gcc-4.3, obwohl der zum Kernelbau verwendete gcc der
gcc-4.1 ist. Also klug ist das nicht...
Gruß
Henning
--
henning paul home: http://home.arcor.de/henning.paul
PM: henni...@gmx.de , ICQ: 111044613
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> "EDITOR" systemweit: "/etc/profile" oder (z.B.) "/etc/profile.d/
> editor.sh". Spezielle Userwünsche: "/.profile".
Das ist nicht wirklich "systemweit" weil es User mit z.B. csh oder tcsh
als Login-Shell nicht erfasst. Die Stelle fuer die wirklich systemweiten
Default-Einstellungen fuer das Einvironment ist /etc/environment.
Thomas Hochstein
>> Keygen: ssh-keygen -t dsa
>
> Warum dsa?
Rollenspieler?
Christian Brabandt
> ed ist selbstverst�ndlich *kein* Editor in diesem Sinne.
Warum?
regards,
Christian
--
hundred-and-one symptoms of being an internet addict:
49. You never have to deal with busy signals when calling your ISP...because
you never log off.
Christian Brabandt
> Realname [m] wrote:
>> vim aufgeblasen? Weil er Umlaute kann? *lol*
>
> [dakini]~$ ls -l --sort=size -r /usr/bin/nvi /usr/bin/elvis /usr/bin/vim
> -rwxr-xr-x 3 root root 30354 2009-04-05 15:39 /usr/bin/nvi*
> -rwxr-xr-x 1 root bin 437596 2004-02-22 07:25 /usr/bin/elvis*
> -rwxr-xr-x 1 root root 4192356 2009-08-25 03:04 /usr/bin/vim*
>
> 4MB f�r was, was man auch in 30K erledigen kann, das nenne ich auch
> aufgeblasen.
Was ist das denn f�r ein Vim?
Ich habe hier:
#v+
chrisbra t41:~ [1059]% ls -l /usr/bin/{vim.*,nvi}
-rwxr-xr-x 3 root root 376836 Jul 24 13:12 /usr/bin/nvi
-rwxr-xr-x 1 root root 1498420 Nov 8 23:08 /usr/bin/vim.basic
-rwxr-xr-x 1 root root 1979980 Nov 8 23:08 /usr/bin/vim.gtk
-rwxr-xr-x 1 root root 630428 Nov 8 23:08 /usr/bin/vim.tiny
#v-
Vim.GTK ist ein Vim 7.2.284, wo so ziemlich alles einkompiliert ist.
Aber gut, mein nvi ist auch um eine Gr��enordnung aufgebl�hter als
Deiner.
regards,
Christian
--
hundred-and-one symptoms of being an internet addict:
48. You get a tatoo that says "This body best viewed with Netscape 3.1 or
higher."
Marc Haber
>Welchen Nutzen hat denn dann der Debian-Mechanismus
Einen sinnvollen Default auch für die User, die ohne eigene
Login-Scripts daherkommen, oder wenn man sudo benutzt was einem das
Environment leerfegt.
Marc Haber
>"EDITOR" systemweit: "/etc/profile" oder (z.B.) "/etc/profile.d/
Das ist abhängig von Shells, die /etc/profile beachten oder eben
nicht, und greift z.B. nicht, wenn Du Dich über xdm etc einloggst.
Marc Haber
>Du meintest am 03.01.10:
>> Dummes Programm, kann nur VISUAL/EDITOR und nimmt in deren
>> Abwesenheit hartcodiert immer vi?
>
In der Tat. Die 70er sind vorbei.
Marc Haber
>Marc Haber wrote:
>> Bernd Hohmann <bernd.hohma...@freihaendler.com> wrote:
>>>Keygen: ssh-keygen -t dsa
>>
>> Warum dsa?
>
>Warum nicht?
Meine Kryptografiekenntnisse sind eingestaubt, aber ich meine mich
daran zu erinnern, dass die kryptografischen Eigenschaften von DSA bei
Keygrößen jenseits der 1024 bit nicht im Detail untersucht sind/waren.
RSAs Sicherheit hängt auch bei größeren Schlüsseln IIRC nachweisbar
ausschließlich von der "Sicherheit" der Primfaktorzerlegung ab.
Deswegen: Bei mir RSA.
Markus Wichmann
> Hel...@Hullen.de (Helmut Hullen) wrote:
>>Du meintest am 03.01.10:
>>> Dummes Programm, kann nur VISUAL/EDITOR und nimmt in deren
>>> Abwesenheit hartcodiert immer vi?
>>
>>Aha - ein Programm, das sich "klassisch" verhält, ist dumm?
>
> In der Tat. Die 70er sind vorbei.
>
> Grüße
> Marc
>
Alt != veraltet. Mir fällt kein besserer Mechanismus ein, um die Frage
nachdem Editor (und wo wir schon dabei sind: dem Pager, MUA, NUA,
Browser und File-Manager), den der Nutzer am liebsten hätte, zu
beantworten. Man kann in seiner .${SHELL}rc diese Variablen pro Nutzer
setzen, nicht wie update-alternatives pro System.
Tschö,
Markus
--
Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart
terminals.
Florian Diesch
> Marc Haber (mh+usene...@zugschl.us) schrieb:
>> Hel...@Hullen.de (Helmut Hullen) wrote:
>>>Du meintest am 03.01.10:
>>>> Dummes Programm, kann nur VISUAL/EDITOR und nimmt in deren
>>>> Abwesenheit hartcodiert immer vi?
>>>
>>>Aha - ein Programm, das sich "klassisch" verh�lt, ist dumm?
>>
>> In der Tat. Die 70er sind vorbei.
>
> Alt != veraltet. Mir f�llt kein besserer Mechanismus ein, um die Frage
> nachdem Editor (und wo wir schon dabei sind: dem Pager, MUA, NUA,
> Browser und File-Manager), den der Nutzer am liebsten h�tte, zu
> beantworten. Man kann in seiner .${SHELL}rc diese Variablen pro Nutzer
> setzen, nicht wie update-alternatives pro System.
Mit den Alternatives kann man systemweite Standardwerte setzen, die der
Nutzer dann bei Bedarf mit Umgebungsvariablen �berschreiben kann - dsas
sind also zwei ganz unterschiedliche Dinge.
Ich finde es sinnvoll, als Admin diese Standardwerte selbst setzen zu
k�nnen, statt auf hartkodierte Einstellungen angewiesen zu sein.
Florian
--
<http://www.florian-diesch.de/software/easygconf/>
Helmut Hullen
Du meintest am 05.01.10:
>>>> Dummes Programm, kann nur VISUAL/EDITOR und nimmt in deren
>>>> Abwesenheit hartcodiert immer vi?
>>> Aha - ein Programm, das sich "klassisch" verh�lt, ist dumm?
>> In der Tat. Die 70er sind vorbei.
> Alt != veraltet. Mir f�llt kein besserer Mechanismus ein, um die
> Frage nachdem Editor (und wo wir schon dabei sind: dem Pager, MUA,
> NUA, Browser und File-Manager), den der Nutzer am liebsten h�tte, zu
> beantworten. Man kann in seiner .${SHELL}rc diese Variablen pro
> Nutzer setzen, nicht wie update-alternatives pro System.
Nur zur Erg�nzung:
which pico
f�hrt hier (Ubuntu 9.10) zu "/etc/alternatives/pico", und dieser Eintrag
wiederum f�hrt zu "/bin/nano".
Sieht nach BOFH-All�ren aus, wenn ich als ONU "pico" aufrufe und infolge
der Definitionen des Systembetreuers bei "nano" lande.
Helmut Hullen
Du meintest am 06.01.10:
> Mit den Alternatives kann man systemweite Standardwerte setzen, die
> der Nutzer dann bei Bedarf mit Umgebungsvariablen �berschreiben kann
> - das sind also zwei ganz unterschiedliche Dinge.
"man"? Das ist der BOFH.
> Ich finde es sinnvoll, als Admin diese Standardwerte selbst setzen zu
> k�nnen, statt auf hartkodierte Einstellungen angewiesen zu sein.
Es ist nicht Aufgabe des Systembetreuers, "f�r alle" so etwas nach
seinem ganz speziellen Geschmack umzudefinieren. Wenn ich als ONU "pico"
aufrufe, dann will ich "pico" haben und nicht (nach dem Willen des BOFH)
z.B. "nano".