| neue Message hinzufügen |

kili 2008-08-22 00:31:28
Vergiss' das mit dem "@", das war Unfug. Ohne den '@' (also so, wie ich es im Beispiel urspruenglich genannt hatte), wuerde es einem eingeloggten User "kili" die Logmessages in alle laufenden Shells / XTerms schreiben -- wie gesagt ziemlich nervig.

Wenn Du Syslogmessages in ein Script schubsen willst, sollte etwas wie

auth.info    |/home/didi/syslogbeep

tun. Das Script /home/didi/syslogbeep wuerde dann bei Bedarf automatisch von syslogd gestartet und mit allen zu auth.info passendne Logmessages befuettert. Da koennte man dann also so etwas reinpacken:

#!/bin/sh
while read logmsg; do
        case "$logmsg" in
        *"Failed password for didi from"*)
                # Hier kommt dann der Code, der es piepsen laesst, den
                # Koelner Dom in die Luft sprengt, oder einen Kasten Bier
                # ordert.
                ;;
        esac
done

Und wenn Du den Koelner Dom nur bei gueltigen Logins in die Luft sprengen willst, dann nimmst Du halt ein entsprechendes Pattern in dem case-Statement.

-- Kili

Aha - ein @? Didi 2008-08-21 13:04:11
Und was macht das @ dann? Ist etwa das "kili" ein script??? Das wär ja fein!

:)idi

jetzt mal hier mit dem mobbing aufhoeren... kili 2008-08-19 22:14:06
quabla, schaem' dich.

didi: da ist irgendwo ein Klammeraffe verlorengegangen. Statt "kili" sollte da "@kili" in der syslog.conf stehen.

kili isn weichei. quabla 2008-08-19 16:25:30
Der antwortet erst wenn er weiss worum's wirklich geht

*hinzufüg* Didi 2008-08-19 15:29:24

Und damit will ich die Antworten von Quabla und RealMurphy nicht vergessen - ich hätte schreiben müssen "... dass, sobald Kili den Thread findet, darauf eine mega-krasse Antwort kommt, die [..]"...

Bin jetzt mal gespannt, ob ich's kapiert hab oder net

:)idi

Ich dachte mir doch... Didi 2008-08-19 15:20:58
... dass, sobald Kili den Thread findet, darauf eine Antwort kommt... (die zwar sicherlich richtig, aber für den Laien nicht einfach zu verstehen ist - und dazu zähl ich mich in dem Fall auch)

Ich hab jetzt mal nen ordentlichen syslogd auf der Box installiert, da dieses Mini-Linux erst mal nur die BusyBox verwendet hat - und da is nix mit configscript.

Sehe ich das jetzt richtig, dass in dem Beispiel der syslog.conf alle einträge, die mit "auth.info" markiert sind, sowohl in /var/log/wohinauchimmer sowie in eine zweites Log (namens kili, location unbestimmt) geschrieben werden?

Richtig kapiert?

:)idi

Und noch einer.... kili 2008-08-15 18:36:42
Ich sehe gerade erst Didis Anforderung (Login-Piepser).

Das wird mit einem Wrapperscript nicht gehen, weil der sshd normalerweise staendig laeuft
und beim Login lediglich einen Childprozess fiorkt.  Das sieht man sehr schoen, wenn man mal
pstree(1) anwirft.

Da  ging dann der Hinweis, sich per Script aufs authlog zu klemmen, schon in die richtige Richtung. Sauberer waere es aber, den syslogd(8) so zu konfigurieren, dass auth.info zusaetzlich zum Logfile auch noch in das Piepserscript gepiped wird (wie das geht, haengt aber vom verwendeten Betriebssystem und syslogd(8) ab). Oder auth.info auf die TTYs bestimmter User schicken, was aber manchmal ziemlich nerven kann ;-)

Ich habe auf einer meiner Maschinen, auf der man sich von aussen einloggen kann, z.B. folgendes in /etc/syslog.conf (klassischer BSD-syslogd):

auth.info                                               /var/log/authlog
auth.info                                               kili

kili 2008-08-15 18:27:32
$@ ohne double quotes macht das gleiche wie $* und macht nicht das, was Didi will, sobald einer
der Parameter Leerzeichen enthaelt. Kann man auch ganz einfach ueberpruefen:

(Alles mit '$' am Anfang sind eingegebene Kommandos, die ^D im cat sind halt Control-D, also EOF)

$ cat > /tmp/foo
#!/bin/sh
exec /tmp/bar $@
^D
$ cat > /tmp/bar
#!/bin/sh
for a; do echo "$a"; done
^D
$ chmod +x /tmp/{foo,bar}
$ /tmp/foo 'a b' 'c d'
a
b
c
d
$ cat > /tmp/foo
#!/bin/sh
exec /tmp/bar "$@"
^D
$ /tmp/foo 'a b' 'c d'
a b
c d


Das "exec" in /tmp/foo ist sinnvoll, wenn /tmp/bar das letzte aufgerufene Kommando ist, da man sich in diesem Fall das fork sparen kann (es wird kein eigener Prozess fuer /tmp/bar gestartet, sondern der Prozess von /tmp/foo wird durch /tmp/bar ersetzt).

RealMurphy 2008-08-15 11:57:27
Evtl. /var/log/auth überwachen mit einem eigenen script?

Danke... Didi 2008-08-15 11:05:50
... schon mal - mal schauen, ob's tut...

Es geht mir dabei ja nicht um den einmaligen Start, sondern darum, dass ja wohl bei jedem neuen Login eine neue Instanz gestartet wird.

Eigentliches Ziel:
Ich hab ne NSLU2 daheim (Festplatten-Dings, Mini-Linux drauf) und würd eigentlich gern haben, dass dieses Ding bei jeder neuen Anmeldung kurz mal piepst bzw. eigentlich bei jedem Login-Versuch.

Ob das jetzt die sshd is oder net wird sich noch zeigen müssen.

Evtl. ne andere Idee?

:)idi

nochwas... quabla 2008-08-15 10:48:32
ich weiss nicht ob das so ganz der richtige Weg ist. Vielleicht bringst du, was auch immer du tun willst lieber in /etc/init.d/sshd unter?

$@ quabla 2008-08-15 10:47:05
ich hoffe das wird jetzt nicht irgendwie als sonderzeichenmuell hier dargestellt...

ein
sshd $@
also
sshd dollar-ätt
sollte das sein was du suchst - das enthaelt alle kommandozeilenparameter.

Frage und die Linuxer und Unixer Didi 2008-08-15 10:43:36
Huhu,

kann mir einer sagen, wie ich ein "Wrapper-Script" machen kann, das ich anstelle des eigentlichen Programms einfügen kann und welches das eigentliche dann mit allen Übergabeparametern später aufruft?

Hä?? Was will Didi??

OK, anders: Ich will statt

/opt/bin/sshd

ein eigenes script /opt/bin/sshd dorthin kopieren, das irgendwas tut und dann eben /opt/bin/original_sshd aufruft - und das mit allen evtl. angegebenen Kommandozeilenparametern

muss ich da dann ein

sshd $1 $2 $3 $4 $5 ...

reinhauen, oder gibt's da was schöneres?

Oder tut das aus irgendeinem Grund so mal gar nicht?

:)idi

| neue Message hinzufügen |
| Anfang | Vorherige | Nächste |

Brought to you by Didi

Letzter Satz im Chat:
Kev (14:34): So, jetzt wieder bei 0 Spielen dran - entschuldigt die Blockade die letzte Woche; zu viele Ereignisse, die vorbereitet und gefeiert werden wollten ;)