Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.folklore.computer > #40917 > unrolled thread

ULTRIX /bin/sh und telnetd

Back to article view | Back to de.alt.folklore.computer

Contents

  ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-21 23:01 +0000
    Re: ULTRIX /bin/sh und telnetd poc@pocnet.net - 2023-06-23 11:21 +0000
      Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-23 14:47 +0000
        Re: ULTRIX /bin/sh und telnetd poc@pocnet.net - 2023-06-23 15:22 +0000
          Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-23 18:32 +0000
            Re: ULTRIX /bin/sh und telnetd Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-06-24 08:34 +0000
            Re: ULTRIX /bin/sh und telnetd Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> - 2023-06-24 12:44 +0200
              Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-24 11:13 +0000
                Re: ULTRIX /bin/sh und telnetd Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> - 2023-06-24 14:22 +0200
                  Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-24 19:29 +0000
            Re: ULTRIX /bin/sh und telnetd Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2023-06-24 11:58 +0200
              Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-24 11:04 +0000
            Re: ULTRIX /bin/sh und telnetd Marco Scholz <tool@disroot.org> - 2023-07-13 16:38 +0000
              Re: ULTRIX /bin/sh und telnetd Marco Scholz <tool@disroot.org> - 2023-07-16 16:04 +0000
                Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-07-17 07:42 +0000
              Re: ULTRIX /bin/sh und telnetd Marco Scholz <tool@disroot.org> - 2023-08-02 11:54 +0000
                Re: ULTRIX /bin/sh und telnetd Christian Corti <use@reply.to> - 2023-08-02 14:23 +0200
                  Re: ULTRIX /bin/sh und telnetd Marco Scholz <tool@disroot.org> - 2023-08-02 15:51 +0000
                Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-08-03 19:06 +0000
                  Re: ULTRIX /bin/sh und telnetd Marco Scholz <tool@disroot.org> - 2023-08-07 16:18 +0000
                    Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-08-07 17:21 +0000
                      Re: ULTRIX /bin/sh und telnetd Marco Scholz <tool@disroot.org> - 2023-08-08 07:39 +0000
                        Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-08-08 08:05 +0000
                          Re: ULTRIX /bin/sh und telnetd poc@pocnet.net - 2023-08-08 11:39 +0000
                            Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-08-08 16:11 +0000
                Re: ULTRIX /bin/sh und telnetd Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2023-08-03 21:31 +0200
                  Re: ULTRIX /bin/sh und telnetd "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-08-03 23:14 +0200
        Re: ULTRIX /bin/sh und telnetd Hanno Foest <hurga-news2@tigress.com> - 2023-06-23 18:02 +0200
          Re: ULTRIX /bin/sh und telnetd "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-23 18:23 +0200
            Re: ULTRIX /bin/sh und telnetd Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> - 2023-06-23 18:28 +0200
              Re: ULTRIX /bin/sh und telnetd "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-23 18:59 +0200
                Re: ULTRIX /bin/sh und telnetd Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> - 2023-06-24 12:40 +0200
                  Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-24 11:24 +0000
    Re: ULTRIX /bin/sh und telnetd Christian Corti <use@reply.to> - 2023-06-22 11:27 +0200
      Re: ULTRIX /bin/sh und telnetd Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2023-06-26 14:20 +0000

Page 1 of 2  [1] 2  Next page →

#40917 — ULTRIX /bin/sh und telnetd

Hallo,

ich habe ein seltsames Problem mit ULTRIX 4.1 und 4.2 festgestellt.
Der telnetd verlangt zwingend die originale BSD /bin/sh, die bei
ULTRIX dabei ist. Normalerweise ersetze ich seit > 20 Jahren
die /bin/sh durch was anderes, z.B. eine bash oder pdksh. Das
ist unter ULTRIX in meiner Erinnerung noch nie schief gegangen
und funktioniert wunderbar für ULTRIX 4.3 oder neuer und auch
für ULTRIX 3.X. Aber halt nicht für 4.1 und 4.2. Einzig sichtbarer
Effekt ist der telnetd, aber das eben absolut reproduzierbar.
Wenn ich die /bin/sh ändere, dann kann sich niemand mehr einloggen,
auch wenn die login shell z.B. /bin/csh ist.

Kann sich das jemand irgendwie erklären? Ich dachte immer die
/bin/sh ist unter ULTRIX so oder so derart alt, dass da kaum
mehr substantielle Unterschiede vorkommen könnten.
Was könnte sich da ändern zwischen ULTRIX 4.2 und 4.3?
Das müsste so 1992 / 1993 sein.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [next] | [standalone]

#40956

Dennis Grevenstein <dennis.grevenstein@gmail.com> wrote:

> Einzig sichtbarer Effekt ist der telnetd, aber das eben absolut
> reproduzierbar.  Wenn ich die /bin/sh ändere, dann kann sich niemand mehr
> einloggen, auch wenn die login shell z.B. /bin/csh ist.

Generell wäre interessant was genau "geht nicht" bedeutet.

Fehlermeldungen, Log-Einträge, etc?

-- 

:wq! PoC

[toc] | [prev] | [next] | [standalone]

#40959

poc@pocnet.net wrote:
> 
> Generell wäre interessant was genau "geht nicht" bedeutet.
 
Man kann auf die Maschine telneten, bekommt ein normales login:
und kann sich einloggen. Das scheint zu funktionieren, aber in
dem Moment, wo man normalerweise einen shell prompt erwarten
würde, bricht das alles ab mit "connection closed by foreign host".

Ich habe es soweit raus, dass dieses Problem mit ULTRIX 4.1
und 4.2 auftritt, aber nicht mit 4.3A und neuer.
Da die als BSD Bourne shell richtig gammelig ist, ersetze ich
die gerne durch eine bash oder pdksh und bislang war meine
Erfahrung, dass das unter ULTRIX gut funktioniert.
Ausserdem diesem telnet Problem sind mir auch keine anderen
Dinge aufgefallen. Daher überlege ich noch, ob man eventuell
auch den telnetd ersetzen könnte.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#40961

Dennis Grevenstein <dennis.grevenstein@gmail.com> wrote:

> Man kann auf die Maschine telneten, bekommt ein normales login:
> und kann sich einloggen. Das scheint zu funktionieren, aber in
> dem Moment, wo man normalerweise einen shell prompt erwarten
> würde, bricht das alles ab mit "connection closed by foreign host".

Danke für die Beschreibung. Das klingt mir ja fast danach als würde der
Shellprozess entweder gar nicht gestartet oder ranzt nach dem Starten ab.

Passiert das bei jedem User? Hast Du mal geprüft ob Du das ggfs. auf
irgendwelche /etc/profile oder ~/.profile zurückführen kannst
(auskommentieren von Einträgen)?

-- 

:wq! PoC

[toc] | [prev] | [next] | [standalone]

#40969

poc@pocnet.net wrote:
>
> Danke für die Beschreibung. Das klingt mir ja fast danach als würde der
> Shellprozess entweder gar nicht gestartet oder ranzt nach dem Starten ab.

Ich habe das jetzt soweit eingegrenzt, dass es irgendwie beim
booten und durchlaufen der init scripte Probleme geben muss.
Wenn ich das System mit der originalen /bin/sh boote und danach
die sh austausche, dann klappt alles. Wenn ich aber die pdksh
oder bash als /bin/sh lasse, dann geht es nicht, selbst wenn ich
danach wieder die originale ULTRIX /bin/sh als sh einsetze.
Das schliesst dann schonmal den telnetd und login als Ursache
aus. Ich kann sogar den telnetd von ULTRIX 4.5 auf 4.1 umkopieren
und der läuft, aber das Problem bleibt bestehen.

Eure Ideen das zu debuggen sind ja nicht verkehrt. ULTRIX hat
auch trace(1), aber den bootprozess will ich vielleicht doch
nicht debuggen.
Insgesamt wundert es mich nur sehr, warum z.B. pdksh nicht
geht, denn das sollte ja einfach nur ksh88 sein. Das sollte
zumindest im Prinzip vollständig abwärtskompatibel sein.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#40975

Dennis Grevenstein <dennis.grevenstein@gmail.com> wrote:
> Insgesamt wundert es mich nur sehr, warum z.B. pdksh nicht
> geht, denn das sollte ja einfach nur ksh88 sein. Das sollte
> zumindest im Prinzip vollständig abwärtskompatibel sein.

Es könnte ja umgekehrt sein: die /bin/sh der von dir getesten Ultrix
Versionen ist irgendwie fehlerhaft und eines der Skripte in der
Bootphase "braucht" diesen Fehler?

Gruß,
Enrik

[toc] | [prev] | [next] | [standalone]

#40977

Dennis Grevenstein <dennis.grevenstein@gmail.com> writes:

> Ich habe das jetzt soweit eingegrenzt, dass es irgendwie beim
> booten und durchlaufen der init scripte Probleme geben muss.
> Wenn ich das System mit der originalen /bin/sh boote und danach
> die sh austausche, dann klappt alles. Wenn ich aber die pdksh
> oder bash als /bin/sh lasse, dann geht es nicht, selbst wenn ich
> danach wieder die originale ULTRIX /bin/sh als sh einsetze.
> Das schliesst dann schonmal den telnetd und login als Ursache
> aus. Ich kann sogar den telnetd von ULTRIX 4.5 auf 4.1 umkopieren
> und der läuft, aber das Problem bleibt bestehen.

Ein Schuss ins Blaue: lmf? Geht das Aktivieren der Lizenzen schief?

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#40980

Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> wrote:
> 
> Ein Schuss ins Blaue: lmf? Geht das Aktivieren der Lizenzen schief?

Das hatte ich tatsächlich sogar gecheckt und es wurde mir alles
entsprechend gelistet:
# lmf list
Product                   Status                     Users: Total      Active

ULTRIX                    active                            unlimited

Aber selbst wenn nicht, würde es trotzdem mit dem default von 2
usern noch ausreichen.

Aber was ich gesehen habe ist, dass /etc/license immer nur anzeigt:
# license
System supports 2 users (the default).

Das ist aber unabhängig von dem shell Problem. Aber normalerweise
hätte ich erwartet, dass da auch was von "unlimited" steht.
license gehört doch eher in die ULTRIX 3 Zeit und nicht mehr
zu ULTRIX 4.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#40983

Dennis Grevenstein <dennis.grevenstein@gmail.com> writes:

> Aber was ich gesehen habe ist, dass /etc/license immer nur anzeigt:
> # license
> System supports 2 users (the default).

> Das ist aber unabhängig von dem shell Problem. Aber normalerweise
> hätte ich erwartet, dass da auch was von "unlimited" steht.
> license gehört doch eher in die ULTRIX 3 Zeit und nicht mehr
> zu ULTRIX 4.

Das ist vermutlich nur aus Gründen der Rückwärts-Kompatibilität zu Ultrix
3 drauf. IMHO kam LMF erst mit Ultrix 4.

# uname -a
ULTRIX gemini 4.5 0 VAX
# /etc/license
System supports 2 users (the default).
# echo 1 >/upgrade
# /etc/license
System supports 49 users.

;-)

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#40988

Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> wrote:
> 
> Das ist vermutlich nur aus Gründen der Rückwärts-Kompatibilität zu Ultrix
> 3 drauf. IMHO kam LMF erst mit Ultrix 4.
> 
> # uname -a
> ULTRIX gemini 4.5 0 VAX
> # /etc/license
> System supports 2 users (the default).
> # echo 1 >/upgrade
> # /etc/license
> System supports 49 users.
 
super. Das war mir komplett unbekannt.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#40978

Dennis Grevenstein meinte:

> Ich habe das jetzt soweit eingegrenzt, dass es irgendwie beim
> booten und durchlaufen der init scripte Probleme geben muss.
> Wenn ich das System mit der originalen /bin/sh boote und danach
> die sh austausche, dann klappt alles

Unbd wenn du in /etc/passwd für den Benutzer, der sich per telnetd 
einloggen will, statt /bin/sh eine andere Shell einträgst? Also nicht 
/bin/sh komplett austauschst, ondern einfach nicht benutzt?
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#40979

Diedrich Ehlerding <diedrich.ehlerding@t-online.de> wrote:
>
> Unbd wenn du in /etc/passwd für den Benutzer, der sich per telnetd 
> einloggen will, statt /bin/sh eine andere Shell einträgst? Also nicht 
> /bin/sh komplett austauschst, ondern einfach nicht benutzt?

Es geht eigentlich mehr um configure scripte und so Zeugs.
Da kann man zwar prinzipiell $CONFIG_SHELL setzen, aber viel
alte software nimmt trotzdem als default /bin/sh an und verlangt
dann zum durchlaufen der scripte features, die die alte ULTRIX
/bin/sh nicht kann (long lines z.B.).
Für non-root user kann man natürlich einfach eine bash eintragen.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#41261

On 2023-06-23, Dennis Grevenstein <dennis.grevenstein@gmail.com> wrote:
> Insgesamt wundert es mich nur sehr, warum z.B. pdksh nicht
> geht, denn das sollte ja einfach nur ksh88 sein. Das sollte
> zumindest im Prinzip vollständig abwärtskompatibel sein.

pdksh ist nicht ksh88.
ksh88 führt blocks im originalen shell Kontext aus, während pdksh
subshells/ subprocesses spawnt und die blocks werden dann nicht im
originalen Kontext ausgeführt.
pdksh hat auch nicht alle feautures von ksh88.
Wenn man das weiss, kann man es umgehen und scripte schreiben, die unter
beiden shells laufen.
Aber ältere scripte (zB. von älteren Unices) unter pdksh auszuführen
kann zu Problemen führen.


-- 
XMPP tool@disroot.org
DB4CE71C8DEF84257AD0B23E4D5934D90226C7F3                      00000100 ⌁

[toc] | [prev] | [next] | [standalone]

#41293

On 2023-07-13, Marco Scholz <tool@disroot.org> wrote:
> ksh88 führt blocks im originalen shell Kontext aus, während pdksh
> subshells/ subprocesses spawnt und die blocks werden dann nicht im
> originalen Kontext ausgeführt.

Ein Beispiel:

x="geht nicht"
echo "geht" | read x; echo $x

Unter ksh88 (oder ksh93) wird "geht" ausgegeben, da das Überschreiben
von x in der selben shell passiert.

Bei pdksh (auch bash) wird "geht nicht" ausgegeben, da die pipe eine
subshell startet, die den vorherigen Kontext nicht kennt. Und dadurch
wird x nicht überschrieben...


-- 
XMPP tool@disroot.org
DB4CE71C8DEF84257AD0B23E4D5934D90226C7F3                      00000100 ⌁

[toc] | [prev] | [next] | [standalone]

#41306

Marco Scholz <tool@disroot.org> wrote:
> 
> Ein Beispiel:
> 
> x="geht nicht"
> echo "geht" | read x; echo $x
> 
> Unter ksh88 (oder ksh93) wird "geht" ausgegeben, da das Überschreiben
> von x in der selben shell passiert.
> 
> Bei pdksh (auch bash) wird "geht nicht" ausgegeben, da die pipe eine
> subshell startet, die den vorherigen Kontext nicht kennt. Und dadurch
> wird x nicht überschrieben...
 
Ich kann mal schauen, ob in den Startskripts von ULTRIX sowas
vorkommt. Es ist jedenfalls ein interessanter Gedanke. Danke Dir.

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#41498

On 2023-07-13, Marco Scholz <tool@disroot.org> wrote:
> pdksh ist nicht ksh88.

In dem Zusammenhang möchte ich noch kurz auf das script

"What shell is this? Here is a script which tries to determine the very
version for all bourne and bourne-compatible shells." 

https://www.in-ulm.de/~mascheck/various/whatshell/

von Sven Maschek hinweisen.

Vielleicht ist es für den einen oder anderen hier von Interesse.

Ein einfaches
 $ echo "$SHELL"
oder
 $ ps -p $$
gibt z.B. auf einem OpenBSD system nur
 /bin/ksh aus. 

Das script zeigt dann aber eine pdksh:
 @(#)PD KSH v5.2.14 99/07/ 
Was korrekt ist.


-- 
XMPP tool@disroot.org
DB4CE71C8DEF84257AD0B23E4D5934D90226C7F3                      00000100 ⌁

[toc] | [prev] | [next] | [standalone]

#41499

Marco Scholz <tool@disroot.org> wrote:
> Das script zeigt dann aber eine pdksh:
>  @(#)PD KSH v5.2.14 99/07/ 
> Was korrekt ist.

Also im Prinzip ein
# what `which $SHELL`


Christian

[toc] | [prev] | [next] | [standalone]

#41500

On 2023-08-02, Christian Corti <use@reply.to> wrote:
> Also im Prinzip ein
> # what `which $SHELL`

Die trivialen Fälle werden in dem script vorab mit einer Anfrage zur
Version abgearbeitet (bash, zsh, sh, ksh, posh, yash), also z.B.:
 $ echo "$KSH_VERSION"


-- 
XMPP tool@disroot.org
DB4CE71C8DEF84257AD0B23E4D5934D90226C7F3                      00000100 ⌁

[toc] | [prev] | [next] | [standalone]

#41543

Marco Scholz <tool@disroot.org> wrote:
> 
> In dem Zusammenhang möchte ich noch kurz auf das script
> 
> "What shell is this? Here is a script which tries to determine the very
> version for all bourne and bourne-compatible shells." 
> 
> https://www.in-ulm.de/~mascheck/various/whatshell/
 
sehr nett.

# sh whatshell.sh 
7th edition Bourne shell, # comments (BSD, or port)
# ksh whatshell.sh 
ksh88 Version (..-)11/16/88 (1st release)
# pdksh whatshell.sh 
@(#)PD KSH v5.2.14 99/07/13.2
# sh5 whatshell.sh 
SVR2 Bourne shell

und kurz nach dem Test von sh5 ist die Kiste dann gecrasht.
ULTRIX...

gruss,
Dennis

-- 
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[toc] | [prev] | [next] | [standalone]

#41565

On 2023-08-03, Dennis Grevenstein <dennis.grevenstein@gmail.com> wrote:
[...]
> # sh5 whatshell.sh 
> SVR2 Bourne shell
>
> und kurz nach dem Test von sh5 ist die Kiste dann gecrasht.
> ULTRIX...

Wie!? Sie ist *nach* der Ausführung gecrasht? Wie ist das denn
passiert? Kannst Du das tracen?

Oder während der Ausführung? Dann schau ihr doch mal mit sh5 -x beim
Ausführen über die Schulter.


-- 
XMPP tool@disroot.org
DB4CE71C8DEF84257AD0B23E4D5934D90226C7F3                      00000100 ⌁

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.alt.folklore.computer

csiph-web