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

Groups > de.comp.os.unix.linux.misc > #115602 > unrolled thread

wlan hängt (manchmal)

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-14 07:13 +0100
    Re: wlan hängt (manchmal) Tim Ritberg <tim@server.invalid> - 2021-03-14 11:41 +0100
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-15 07:47 +0100
        Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 11:27 -0400
    Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-14 11:36 -0400
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-15 07:46 +0100
        Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 11:24 -0400
          Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-16 08:23 +0100
            Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-16 07:36 -0400
              Re: wlan hängt (manchmal) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-16 11:59 +0000
                Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-16 11:02 -0400
                  Re: wlan hängt (manchmal) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-16 15:39 +0000
              Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-16 13:21 +0100
            Re: wlan hängt (manchmal) Bernd Mayer <beam.bam.boom@knuut.de> - 2021-03-16 15:20 +0100
              Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-16 15:58 +0100
    Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-16 09:27 -0700
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-17 07:24 +0100
        Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-17 13:16 -0700
          Re: wlan hängt (manchmal) Kay Martinen <usenet@martinen.de> - 2021-03-17 22:22 +0100
            Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-17 15:18 -0700
              Re: wlan hängt (manchmal) [OT] Joerg <news@analogconsultants.com> - 2021-03-17 15:55 -0700
              Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-18 15:19 -0700
                Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 21:35 +0100
                  Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-19 15:21 -0700
                    Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-20 03:46 -0400
                      Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-21 11:46 -0700
                        Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-21 17:23 -0400
                          Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-22 13:02 -0700
                            Re: wlan hängt (manchmal) Kay Martinen <usenet@martinen.de> - 2021-03-22 21:41 +0100
                            Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-22 18:21 -0400
                    Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-20 20:54 +0100
              Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-18 20:46 +0100
                Re: wlan hängt (manchmal) Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-03-18 22:25 +0000
                  Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 21:08 +0100
                    Re: wlan hängt (manchmal) Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-03-20 11:22 +0000
                      Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-20 20:59 +0100
                Re: wlan hängt (manchmal) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-19 12:17 +0100
                  Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 21:12 +0100
            Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-17 18:28 -0400
              Reboot-Verhalten unattended-upgrades (was: wlan hängt (manchmal)) Thomas Stein <tstein@tstein.net> - 2021-03-18 08:38 +0100
                Re: Reboot-Verhalten unattended-upgrades Andreas Kohlbach <ank@spamfence.net> - 2021-03-18 18:34 -0400
                  Re: Reboot-Verhalten unattended-upgrades Thomas Stein <tstein@tstein.net> - 2021-03-22 10:49 +0100
                    Re: Reboot-Verhalten unattended-upgrades Andreas Kohlbach <ank@spamfence.net> - 2021-03-22 14:00 -0400
            Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-18 07:14 +0100
          Re: wlan hängt (manchmal) Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-03-17 23:42 +0100
            Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-17 15:52 -0700
    Re: wlan hängt (manchmal) Bernd Mayer <beam.bam.boom@knuut.de> - 2021-03-16 17:45 +0100
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-17 07:25 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#115745 — Re: wlan hängt (manchmal) [OT]

On 3/17/21 3:18 PM, Joerg wrote:
> On 3/17/21 2:22 PM, Kay Martinen wrote:
>> Am 17.03.21 um 21:16 schrieb Joerg:
>>> On 3/16/21 11:24 PM, Jan Novak wrote:
>>
>>>> Es tritt ja nur 1 mal die Woche, manchmal sogar nur alle 2 Wochen auf.
>>>> Sobald es wieder soweit ist, teste ich das.
>>
>> Da hätte ich noch die Idee im WLAN-Router der da vermutlich involviert
>> ist mal zu schauen wie lange der eine IP Adresse reserviert. Also die
>> leasetime. Wenn die auf 1 Monat steht versucht der Client die nach 2
>> Wochen zu erneuern. Wenn der Router aber inzwischen neu gestartet
>> wurde... Oder irgendwas anderes dazwischen kam...
>>
>> Man könnte die lease-dauer ja testweise mal auf wenige Stunden
>> einstellen und schauen ob das Problem ebenso häufiger auftritt.
>>
> 
> In Jans erstem Post sieht es aber so aus, dass die Verzoegerungen alle 
> paar Millisekunden passieren.
> 
>>
>>> vereinzelt unaufgeforderte Re-Boots stehen, doch da sucht man sich einen
>>
>> cronjob, unattended-updates?
>>
> 
> Es ist ArchLinux, es hat keine cron Eintraege in /etc und es kennt das 
> Command crontab nicht. Muss man m.W. nachinstallieren (cronie?).
> 
> Unattended Updates kann natuerlich sein. Doch dann wuerde ich vor den 
> Re-Boots je mindestens einen Eintrag dazu im Log erwarten.
> 

grep -i upgraded /var/log/pacman.log

liefert keine Eintraege nach November 2020, aber das Dingen ist seit dem 
mehrmals im Leerlauf abgeschmiert.

Vermutlich ist mein Problem aehnlich geartet wie das von Jan.


> Ich bin gerade runter in den Keller, weil ich dann immer einen Power 
> Cycle machen muss. Als ich ankam, blinkte die Zugriffs-LED des USB 
> Sticks, auf dem ArchLinux weilt, durchgehend in schneller Frequenz. 
> Hoffentlich sind das keine Schreibzugriffe. Die Daten sind auf einer SD 
> Card.
> 
> Diesmal kam das NAS im Terminal sehr viel anders zurueck, aber es 
> funktioniert wie sonst:
> 
> $ ssh 10.0.0.54
> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
> ECDSA key fingerprint is 
> SHA256:Y1P8iElhTm+EuI2BXVjlXAAIUMznx/kMZzAF+Nqdxeo.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added '10.0.0.54' (ECDSA) to the list of known hosts.
> joerg@10.0.0.54's password:
> 
> 
> 
>>> Wolf. Nervig ist, dass auch nach Absturz die gruene "Alles paletti"
>>> Betriebs-LED leuchtet, obwohl das Dingen voll festgefroren ist.
>>
>> Die wird doch vermutlich hart auf AN gesetzt so bald der gestartet ist.
> 
> 
> Nee, sie blinkt und geht erst dann auf Dauerlicht, wenn der Pogoplug 
> sich im LAN als verfuegbar meldet.
> 
> 
>> Schlechter Indikator so lange kein tool dauernd läuft das damit blinkt
>> wenn etwas NICHT mehr stimmt.
>>
> 
> Ich habe das ganz dekadent so wie in der Distro gelassen und weiss 
> nicht, wie diese LED software-maessig beschickt wird.
> 
> 
>>> Bei der sich gelegentlich von selbst einschaltenden Schreibtischlampe
>>> meiner Frau habe ich es raus. Wenn ich auf bestimmten Frequenzen im 40m
>>> Band sende, geht die an.
>>
>> Vagabundierende HF? Antenne nicht geerdet? Vielleicht killt das auch
>> deinen Pogoplug. Bei einem raspi-modell reicht eine Blitzlampe. ;-)
>>
> 
> :-)
> 
> Bis da unten im Keller ist es sehr weit von Antennen und Funkstation, 
> auch gut geschirmt. Aber ... nur 2m entfernt steht mein Gaerschrank fuer 
> die Hobbybrauerei und wenn bei dem der fette Kompressor anspringt ...
> 

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#115759

On 3/18/21 12:46 PM, Sieghard Schicktanz wrote:
> Hallo Joerg,
> 
> Du schriebst am Wed, 17 Mar 2021 15:18:40 -0700:
> 
>>> cronjob, unattended-updates?
>>
>> Es ist ArchLinux, es hat keine cron Eintraege in /etc und es kennt das
>> Command crontab nicht. Muss man m.W. nachinstallieren (cronie?).
> 
> Heißt der nicht "chrony"? Aber egal, einen cron-deamon hat Arch sicher
> auch, und wenn's der intern-integrierte systemd-eigene eingebaute Dienst
> ist. Der läuft dann natürlich nach systemd-internen eigenen Regeln...
> 

Irgendwo tief in der Bilch versteckt. Ich kann mir eh nicht vorstellen, 
dass es an einem cronjob liegt, dafuer treten die Aussteiger zu 
unregelmaessig auf.


>> Unattended Updates kann natuerlich sein. Doch dann wuerde ich vor den
>> Re-Boots je mindestens einen Eintrag dazu im Log erwarten.
> ...
>> Diesmal kam das NAS im Terminal sehr viel anders zurueck, aber es
>> funktioniert wie sonst:
>>
>> $ ssh 10.0.0.54
>> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
>> ECDSA key fingerprint is
>> SHA256:Y1P8iElhTm+EuI2BXVjlXAAIUMznx/kMZzAF+Nqdxeo. Are you sure you want
>> to continue connecting (yes/no)? yes Warning: Permanently added
>> '10.0.0.54' (ECDSA) to the list of known hosts. joerg@10.0.0.54's
>> password:
> 
> Also. _DAS_ hätte ich da nicht gemacht. Da hätte ich dann schon erstmal mit
> einem separaten System an dem Ding nachgeschaut, was da los sein kann. BTW,
> hattest Du nicht geschrieben, das Ding liefe von einem USB-Stick? Hast Du
> das Original-System von dem nch wo? Das hätte ich in dem Fall dann einfach
> ersatzweise eingesteckt.
> Die Frage hier ist dann durchaus "ist das jetzt noch _(m|D)ein_ System?"
> 

Nun ja, 10.0.0.54 war schon immer dessen IP Adresse und das ganze 
passierte nach einem Absturz, gefolgt von Re-Boot per Hand (Power 
Cycle). Auch fragte es ja nach meinem Password, was gleich blieb.


> ssh-Schlüssel verändern sich schließlich nicht ohne äußeres Zutun, sie
> sollten das auch bei einem _regulären_ extern angestoßenen Update nicht
> tun. Wenn sie das tun, ist - IMHO - Mißtrauen angebracht, das es erstmal
> auszuräumen gilt.
> 

Wer sollte denn da hinter einer NAT reinschnueffeln?


>>>> Wolf. Nervig ist, dass auch nach Absturz die gruene "Alles paletti"
>>>> Betriebs-LED leuchtet, obwohl das Dingen voll festgefroren ist.
> ...
>> Nee, sie blinkt und geht erst dann auf Dauerlicht, wenn der Pogoplug
>> sich im LAN als verfuegbar meldet.
> 
> Schlecht implementiert. Es wäre besser, wenn sie bei einem erkannten
> Fehler, oder evtl. auch beim Anmelden, "hektisch" (mit hoher Frequenz)
> blinkt und im Normalbetrieb dann "beruhigend" (langsam) weiterblinkt.
> Dann hat man bei Dauerleuchten oder -nichtleuchten sofort einen Indikator,
> daß da was hängt. Hab' ich hier an einem Platinchen, das ein paar Daten
> sammelt, so gemacht.
> 

Koennte man sicher machen, aber dinge deutlich ueber meine 
Programmierfaehigkeiten.


>> Ich habe das ganz dekadent so wie in der Distro gelassen und weiss
>> nicht, wie diese LED software-maessig beschickt wird.
> 
> Dürfte mit einem kleinen Scriptchen einfach bedienbar sein, vielleicht
> gibt's dafür sogar einen Treiber dafür oder einen /sys-File, der die
> schaltet. Sowas wird gerne per "GPIO" (General Purpose In-Output) gemacht.
> 

Die LED haengt an einem GPIO the Kirkwood ARM Prozessors. Wenn es eine 
HW Aenderung waere, kein Problem, aber "Scriptchen" ist fuer meinereins 
zu hoch.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#115820

Hallo Joerg,

Du schriebst am Thu, 18 Mar 2021 15:19:27 -0700:

> >> $ ssh 10.0.0.54
> >> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
> >> ECDSA key fingerprint is
...
> > Also. _DAS_ hätte ich da nicht gemacht. Da hätte ich dann schon erstmal
> > mit einem separaten System an dem Ding nachgeschaut, was da los sein
...
> Nun ja, 10.0.0.54 war schon immer dessen IP Adresse und das ganze 
> passierte nach einem Absturz, gefolgt von Re-Boot per Hand (Power 
> Cycle). Auch fragte es ja nach meinem Password, was gleich blieb.

_Gerade_ weil die Adresse gleich blieb (und dann auch noch das Passwort) -
"nur" der Maschinenschlüssel hat sich geändert. Hast _DU_ ihn geändert?
Nein? Wer dann?
Wenn der durch den Absturz gelöscht worden wäre, solltest Du Dich erstmal
überhaupt nicht mehr anmelden können. (Außer eine - IMHO "etwas"
übereifrige - Funktion legt beim Neustart dann einen neune Schlüssel an.
Das sollte man aber wissen und nachprüfen können -> Logs anschauen.)
Wenn der Schlüssel von außen verändert wurde, dann könnte damit derjenige,
der das gemacht hat, jederzeit Dein Serverchen "besuchen" und mit ihm
beliebiges anstellen.

> Wer sollte denn da hinter einer NAT reinschnueffeln?

Ja, nee, hinter einer normalerweise undurchsichtigen "Wand" ist ja nie
nichts uninteressantes nicht zu vermuten, nicht? Und wenn's nue mal ein
routinemäßiges Einrichten eines "Serice-"Zugangs ist, über den man dann
Spezialfunktionen für externe Nutzung 'reinladen könnte. Es "soll" ja schon
vorgekommen sein, daß solche Gerätchen dann als Teilnehmer an Verteilnetzen
für illegale Daten oder sog. "Bot-Netzen" aufgefunden wurden.
Naja, muß nicht sein. Aber ich würde das lieber sicherstellen.

...
[Betriebs-LED]
> Koennte man sicher machen, aber dinge deutlich ueber meine 
> Programmierfaehigkeiten.

Ahjaklarsicherdoch.
Ein Skriptchen mit 

while true; do
    <schalte LED ein>; sleep 1; <schalte LED aus>; sleep 1
done &

geht ja weit über Deine Hacking-Fähigkeiten. Insbesondere...

> Die LED haengt an einem GPIO the Kirkwood ARM Prozessors. Wenn es eine 
> HW Aenderung waere, kein Problem, aber "Scriptchen" ist fuer meinereins 
> zu hoch.

... wenn das darauf hinausläuft, die beiden Funktionen

<schalte LED ein> mit "echo 1 > /sys/class/gpio/gpio<n>/value" und
<schalte LED aus> mit "echo 0 > /sys/class/gpio/gpio<n>/value"

gemäß Beschreibung der GPIO-Funktionen und abgeschrieben aus dem
Einschalt-Skript für den Netzwerk-Start zu implementieren.
Aber man müßte sich dazu natürlich mal die "G'schicht' anschauen und
nach"forschen", wie sowas gehen kann.
(Gehässige Anmerkung:) Ab welchem Alter ist bei Euch Lernen verboten?

Aber wahrscheinlich gibt's das eh schon fertig im internet.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#115824

On 3/19/21 1:35 PM, Sieghard Schicktanz wrote:
> Hallo Joerg,
> 
> Du schriebst am Thu, 18 Mar 2021 15:19:27 -0700:
> 
>>>> $ ssh 10.0.0.54
>>>> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
>>>> ECDSA key fingerprint is
> ...
>>> Also. _DAS_ hätte ich da nicht gemacht. Da hätte ich dann schon erstmal
>>> mit einem separaten System an dem Ding nachgeschaut, was da los sein
> ...
>> Nun ja, 10.0.0.54 war schon immer dessen IP Adresse und das ganze
>> passierte nach einem Absturz, gefolgt von Re-Boot per Hand (Power
>> Cycle). Auch fragte es ja nach meinem Password, was gleich blieb.
> 
> _Gerade_ weil die Adresse gleich blieb (und dann auch noch das Passwort) -
> "nur" der Maschinenschlüssel hat sich geändert. Hast _DU_ ihn geändert?
> Nein? Wer dann?


Der ist wohl beim Absturz geplaettet worden.


> Wenn der durch den Absturz gelöscht worden wäre, solltest Du Dich erstmal
> überhaupt nicht mehr anmelden können. (Außer eine - IMHO "etwas"
> übereifrige - Funktion legt beim Neustart dann einen neune Schlüssel an.


Ich konnte mich ja auch nach dem ersten Einrichten (post hack) anmelden. 
BTW, fuer den Hack musste ich an den Bootloader und das ging nur per 
serieller Verbindung unter Einsatz des Loetkolbens. Um das in Zukunft 
einfacher zu machen, habe ich eine Klinkenbuchse eingebaut.


> Das sollte man aber wissen und nachprüfen können -> Logs anschauen.)
> Wenn der Schlüssel von außen verändert wurde, dann könnte damit derjenige,
> der das gemacht hat, jederzeit Dein Serverchen "besuchen" und mit ihm
> beliebiges anstellen.
> 

Das waere aehnlich, als ob jemand in eine Streusandkiste einbricht. Kann 
man machen, aber wozu? Ok, auf dem Pogoplug ist immer noch die 
Feuerzangenbowle drauf und vielleicht interessiert der Film ganz 
besonders :-)


>> Wer sollte denn da hinter einer NAT reinschnueffeln?
> 
> Ja, nee, hinter einer normalerweise undurchsichtigen "Wand" ist ja nie
> nichts uninteressantes nicht zu vermuten, nicht? Und wenn's nue mal ein
> routinemäßiges Einrichten eines "Serice-"Zugangs ist, über den man dann
> Spezialfunktionen für externe Nutzung 'reinladen könnte. Es "soll" ja schon
> vorgekommen sein, daß solche Gerätchen dann als Teilnehmer an Verteilnetzen
> für illegale Daten oder sog. "Bot-Netzen" aufgefunden wurden.
> Naja, muß nicht sein. Aber ich würde das lieber sicherstellen.
> 

Dann muesste es massenweise Traffic geben und den gibt es nicht.

> ...
> [Betriebs-LED]
>> Koennte man sicher machen, aber dinge deutlich ueber meine
>> Programmierfaehigkeiten.
> 
> Ahjaklarsicherdoch.
> Ein Skriptchen mit
> 
> while true; do
>      <schalte LED ein>; sleep 1; <schalte LED aus>; sleep 1
> done &
> 
> geht ja weit über Deine Hacking-Fähigkeiten. Insbesondere...
> 
>> Die LED haengt an einem GPIO the Kirkwood ARM Prozessors. Wenn es eine
>> HW Aenderung waere, kein Problem, aber "Scriptchen" ist fuer meinereins
>> zu hoch.
> 
> ... wenn das darauf hinausläuft, die beiden Funktionen
> 
> <schalte LED ein> mit "echo 1 > /sys/class/gpio/gpio<n>/value" und
> <schalte LED aus> mit "echo 0 > /sys/class/gpio/gpio<n>/value"
> 
> gemäß Beschreibung der GPIO-Funktionen und abgeschrieben aus dem
> Einschalt-Skript für den Netzwerk-Start zu implementieren.
> Aber man müßte sich dazu natürlich mal die "G'schicht' anschauen und
> nach"forschen", wie sowas gehen kann.
> (Gehässige Anmerkung:) Ab welchem Alter ist bei Euch Lernen verboten?
>  > Aber wahrscheinlich gibt's das eh schon fertig im internet.
> 

Das hat fuer mich derzeit Prioritaet null. Es gibt wichtigeres. Z.B. ist 
wegen COVID die Organisation von Gottesdiensten nicht so einfach, muss 
ich aber bei mithelfen. Das ist um Groessenordnungen wichtiger as eine 
gruene LED im Keller.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#115826

On Fri, 19 Mar 2021 15:21:19 -0700, Joerg wrote:
>
> On 3/19/21 1:35 PM, Sieghard Schicktanz wrote:
>> Hallo Joerg,
>> ...
>>> Nun ja, 10.0.0.54 war schon immer dessen IP Adresse und das ganze
>>> passierte nach einem Absturz, gefolgt von Re-Boot per Hand (Power
>>> Cycle). Auch fragte es ja nach meinem Password, was gleich blieb.
>> _Gerade_ weil die Adresse gleich blieb (und dann auch noch das
>> Passwort) -
>> "nur" der Maschinenschlüssel hat sich geändert. Hast _DU_ ihn geändert?
>> Nein? Wer dann?
>
>
> Der ist wohl beim Absturz geplaettet worden.

Unwahrscheinlich. Selbst für den Unwahrscheinlichen Fall, dass gerade
*schreibend* (das selbst wäre schon schlecht, wenn Du selbst nicht Hand
anlegtest) abstürzt, sollte das Journal das beim Neustart richten.

Nun habe ich nochmal zurückgespult, um den Zusammenhang zu verstehen. Die
Antwort dürfte sich in
<https://superuser.com/questions/421074/ssh-the-authenticity-of-host-host-cant-be-established>
finden lassen.

Ist da Deine Antwort drin? Dann hätte Dein Google das gefunden. Meiner
hat. Oder ist Dein Google auch abgestürzt? ;-)
-- 
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

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

#115864

On 3/20/21 12:46 AM, Andreas Kohlbach wrote:
> On Fri, 19 Mar 2021 15:21:19 -0700, Joerg wrote:
>>
>> On 3/19/21 1:35 PM, Sieghard Schicktanz wrote:
>>> Hallo Joerg,
>>> ...
>>>> Nun ja, 10.0.0.54 war schon immer dessen IP Adresse und das ganze
>>>> passierte nach einem Absturz, gefolgt von Re-Boot per Hand (Power
>>>> Cycle). Auch fragte es ja nach meinem Password, was gleich blieb.
>>> _Gerade_ weil die Adresse gleich blieb (und dann auch noch das
>>> Passwort) -
>>> "nur" der Maschinenschlüssel hat sich geändert. Hast _DU_ ihn geändert?
>>> Nein? Wer dann?
>>
>>
>> Der ist wohl beim Absturz geplaettet worden.
> 
> Unwahrscheinlich. Selbst für den Unwahrscheinlichen Fall, dass gerade
> *schreibend* (das selbst wäre schon schlecht, wenn Du selbst nicht Hand
> anlegtest) abstürzt, sollte das Journal das beim Neustart richten.
> 
> Nun habe ich nochmal zurückgespult, um den Zusammenhang zu verstehen. Die
> Antwort dürfte sich in
> <https://superuser.com/questions/421074/ssh-the-authenticity-of-host-host-cant-be-established>
> finden lassen.
> 
> Ist da Deine Antwort drin? Dann hätte Dein Google das gefunden. Meiner
> hat. Oder ist Dein Google auch abgestürzt? ;-)
> 

Zitat aus dem Link "He still doesn't have your private key, so he can't 
login at any future time, or to any other resource that key unlocks, but 
he does have one login session".

Dann waere selbst im (sehr unwahrscheinlichen) Fall eines Hack alles 
wieder dicht, weil ich danach zur Probe noch mehrere Re-Boots machte. 
Ein 800MHz 32-bit ARM Prozessor ist heutzutage eh kein lohnendes Ziel mehr.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#115866

On Sun, 21 Mar 2021 11:46:28 -0700, Joerg wrote:
>
> On 3/20/21 12:46 AM, Andreas Kohlbach wrote:
>> On Fri, 19 Mar 2021 15:21:19 -0700, Joerg wrote:
>>>
>> Unwahrscheinlich. Selbst für den Unwahrscheinlichen Fall, dass
>> gerade
>> *schreibend* (das selbst wäre schon schlecht, wenn Du selbst nicht Hand
>> anlegtest) abstürzt, sollte das Journal das beim Neustart richten.
>> Nun habe ich nochmal zurückgespult, um den Zusammenhang zu
>> verstehen. Die
>> Antwort dürfte sich in
>> <https://superuser.com/questions/421074/ssh-the-authenticity-of-host-host-cant-be-established>
>> finden lassen.
>> Ist da Deine Antwort drin? Dann hätte Dein Google das
>> gefunden. Meiner
>> hat. Oder ist Dein Google auch abgestürzt? ;-)
>> 
>
> Zitat aus dem Link "He still doesn't have your private key, so he
> can't login at any future time, or to any other resource that key
> unlocks, but he does have one login session".

Das ist eine der eher unwahrscheinlicheren Szenarien des Problems. Wer
das aber verdächtigt, kann die Login-Session beenden. Für den Fall, dass
der Angreifer nicht root wurde, sollte der Account, indem sich eingeloggt
wurde, entfernt und gegebenenfalls neu erstellt werden.

> Dann waere selbst im (sehr unwahrscheinlichen) Fall eines Hack alles
> wieder dicht, weil ich danach zur Probe noch mehrere Re-Boots machte. 
> Ein 800MHz 32-bit ARM Prozessor ist heutzutage eh kein lohnendes Ziel mehr.

Die Architektur selbst ist uninteressant. Der Inhalt oder Besitzer
schon. Es mag Behörden geben, die Research zur anhaltenden Krise auf
32-Bit Rechnern vorhalten. Chinesen und Russen mögen besonders daran
interessiert sein, interessieren sich aber nicht für die unterliegende
Architektur.
-- 
Andreas

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

#115889

On 3/21/21 2:23 PM, Andreas Kohlbach wrote:
> On Sun, 21 Mar 2021 11:46:28 -0700, Joerg wrote:
>>
>> On 3/20/21 12:46 AM, Andreas Kohlbach wrote:
>>> On Fri, 19 Mar 2021 15:21:19 -0700, Joerg wrote:
>>>>
>>> Unwahrscheinlich. Selbst für den Unwahrscheinlichen Fall, dass
>>> gerade
>>> *schreibend* (das selbst wäre schon schlecht, wenn Du selbst nicht Hand
>>> anlegtest) abstürzt, sollte das Journal das beim Neustart richten.
>>> Nun habe ich nochmal zurückgespult, um den Zusammenhang zu
>>> verstehen. Die
>>> Antwort dürfte sich in
>>> <https://superuser.com/questions/421074/ssh-the-authenticity-of-host-host-cant-be-established>
>>> finden lassen.
>>> Ist da Deine Antwort drin? Dann hätte Dein Google das
>>> gefunden. Meiner
>>> hat. Oder ist Dein Google auch abgestürzt? ;-)
>>>
>>
>> Zitat aus dem Link "He still doesn't have your private key, so he
>> can't login at any future time, or to any other resource that key
>> unlocks, but he does have one login session".
> 
> Das ist eine der eher unwahrscheinlicheren Szenarien des Problems. Wer
> das aber verdächtigt, kann die Login-Session beenden. Für den Fall, dass
> der Angreifer nicht root wurde, sollte der Account, indem sich eingeloggt
> wurde, entfernt und gegebenenfalls neu erstellt werden.
> 

Kann ich machen, aber mein Passwort haette der ja nicht. Es ist auch 
mucksmaeuschenstill auf dem NAS, wenn ich es nicht benutze.


>> Dann waere selbst im (sehr unwahrscheinlichen) Fall eines Hack alles
>> wieder dicht, weil ich danach zur Probe noch mehrere Re-Boots machte.
>> Ein 800MHz 32-bit ARM Prozessor ist heutzutage eh kein lohnendes Ziel mehr.
> 
> Die Architektur selbst ist uninteressant. Der Inhalt oder Besitzer
> schon. Es mag Behörden geben, die Research zur anhaltenden Krise auf
> 32-Bit Rechnern vorhalten. ...


Was fuer eine Krise? :-)


>                        ... Chinesen und Russen mögen besonders daran
> interessiert sein, interessieren sich aber nicht für die unterliegende
> Architektur.
> 

Aha, die wollen also an meine Bierbraurezepte ...

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#115893

Am 22.03.21 um 21:02 schrieb Joerg:
> On 3/21/21 2:23 PM, Andreas Kohlbach wrote:

>> das aber verdächtigt, kann die Login-Session beenden. Für den Fall, dass
>> der Angreifer nicht root wurde, sollte der Account, indem sich eingeloggt
>> wurde, entfernt und gegebenenfalls neu erstellt werden.
> 
> Kann ich machen, aber mein Passwort haette der ja nicht. Es ist auch
> mucksmaeuschenstill auf dem NAS, wenn ich es nicht benutze.

Klingt nach Schönsaufen. Oder da-ist-nix-weil-da-nix-sein-soll.

>> Die Architektur selbst ist uninteressant. Der Inhalt oder Besitzer
>> schon. Es mag Behörden geben, die Research zur anhaltenden Krise auf
>> 32-Bit Rechnern vorhalten. ...
> 
> Was fuer eine Krise? :-)

Schau dich um und such dir eine aus. Irgendwo, irgendwie, irgendwas ist
immer "Krise".

Aber wenn du eine Merkwürdigkeit erzählst und die Guten Ratschläge dazu
dann nicht umsetzen willst weil du davon "überzeugt" bist das nicht zu
brauchen - dann wirst du auch nirgends eine Krise finden. Bis du von ihr
überrollt wirst. ;-)

>>                        ... Chinesen und Russen mögen besonders daran
>> interessiert sein, interessieren sich aber nicht für die unterliegende
>> Architektur.
>>
> 
> Aha, die wollen also an meine Bierbraurezepte ...

Genau. Die haben Ideen-Krise. Und deine Rezepte haben sie längst. Jetzt
kannst du die Schachtel weg werfen. ;-)

Nicht das deine Beratungs-resistenz neu wäre...

Kay

-- 
Posted via leafnode

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

#115895

On Mon, 22 Mar 2021 13:02:15 -0700, Joerg wrote:
>
> On 3/21/21 2:23 PM, Andreas Kohlbach wrote:
>
>>> Dann waere selbst im (sehr unwahrscheinlichen) Fall eines Hack alles
>>> wieder dicht, weil ich danach zur Probe noch mehrere Re-Boots machte.
>>> Ein 800MHz 32-bit ARM Prozessor ist heutzutage eh kein lohnendes Ziel mehr.
>> Die Architektur selbst ist uninteressant. Der Inhalt oder Besitzer
>> schon. Es mag Behörden geben, die Research zur anhaltenden Krise auf
>> 32-Bit Rechnern vorhalten. ...
>
>
> Was fuer eine Krise? :-)

Nur ,eine persönliche Krise. Sonst ist ja eitel Sonnenschein auf der Welt,
und es gibt keine Probleme. ;-)

>>                        ... Chinesen und Russen mögen besonders daran
>> interessiert sein, interessieren sich aber nicht für die unterliegende
>> Architektur.
>> 
>
> Aha, die wollen also an meine Bierbraurezepte ...

Das war ein Beispiel. Deine Rezepte sind vermutlich nicht so wichtig für
die Asiaten.
-- 
Andreas

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

#115847

Hallo Joerg,

Du schriebst am Fri, 19 Mar 2021 15:21:19 -0700:

> >>>> $ ssh 10.0.0.54
> >>>> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be
> >>>> established. ECDSA key fingerprint is  
..
> > _Gerade_ weil die Adresse gleich blieb (und dann auch noch das
> > Passwort) - "nur" der Maschinenschlüssel hat sich geändert. Hast _DU_
> > ihn geändert? Nein? Wer dann?  
...
> Der ist wohl beim Absturz geplaettet worden.

Nachgeprüft? Dann ok. Sonst... Naja, ist _Dein_ risiko.
...
> Ich konnte mich ja auch nach dem ersten Einrichten (post hack) anmelden. 

_Beim_ Einrichten wird ja normalerweise auch ein Maschinenschlüssel
angelegt. Der sollte sich dann aber erst bei der nächsten Neuinstallation
wieder ändern.
Allerdings könnte das auch andersrum schief gelegen haben, nämlich daß auf
der Maschine, von der Du Dich angemeldet hast, der Schlüssel (öffentlicher
Teil) verschusselt worden ist.

> BTW, fuer den Hack musste ich an den Bootloader und das ging nur per 
> serieller Verbindung unter Einsatz des Loetkolbens. Um das in Zukunft 
> einfacher zu machen, habe ich eine Klinkenbuchse eingebaut.

Ja, haste schon erzählt.

...
> > derjenige, der das gemacht hat, jederzeit Dein Serverchen "besuchen"
> > und mit ihm beliebiges anstellen.
> 
> Das waere aehnlich, als ob jemand in eine Streusandkiste einbricht. Kann 
> man machen, aber wozu? Ok, auf dem Pogoplug ist immer noch die 
> Feuerzangenbowle drauf und vielleicht interessiert der Film ganz 
> besonders :-)

Mit Sicherheit. Und wenn die mit einem illegalen Werkchen überschrieben
wird, das dann jeder Interessent mit Zugangswissen abholen kann, dann ...
...
> > Verteilnetzen für illegale Daten oder sog. "Bot-Netzen" aufgefunden
> > wurden. Naja, muß nicht sein. Aber ich würde das lieber sicherstellen.
> 
> Dann muesste es massenweise Traffic geben und den gibt es nicht.

Nee, das muß es - zumindest _noch_ - nicht, und für ein Verteilnetz könnt's
sogar dauernd unauffällig sein. Auch andere "Nutzungen" können versteckt
sein, und schließlich können die Verkehrsdaten ja auch manipuliert werden.
Ist halt alles Dein Risiko.

> > [Betriebs-LED]  
> Das hat fuer mich derzeit Prioritaet null. Es gibt wichtigeres. Z.B. ist 

Auch recht, war ja nur gut gemeint. Aber wenn Du nichts neues lernen
willst, kann ich auch damit leben. Ist ja Dein Leben, das Du ertragen mußt.

> wegen COVID die Organisation von Gottesdiensten nicht so einfach, muss 
> ich aber bei mithelfen. Das ist um Groessenordnungen wichtiger as eine 
> gruene LED im Keller.

Und da gibt es sogar schlechtere Ausreden...

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#115761

Hallo Joerg,

Du schriebst am Wed, 17 Mar 2021 15:18:40 -0700:

> > cronjob, unattended-updates?
> 
> Es ist ArchLinux, es hat keine cron Eintraege in /etc und es kennt das 
> Command crontab nicht. Muss man m.W. nachinstallieren (cronie?).

Heißt der nicht "chrony"? Aber egal, einen cron-deamon hat Arch sicher
auch, und wenn's der intern-integrierte systemd-eigene eingebaute Dienst
ist. Der läuft dann natürlich nach systemd-internen eigenen Regeln...

> Unattended Updates kann natuerlich sein. Doch dann wuerde ich vor den 
> Re-Boots je mindestens einen Eintrag dazu im Log erwarten.
...
> Diesmal kam das NAS im Terminal sehr viel anders zurueck, aber es 
> funktioniert wie sonst:
> 
> $ ssh 10.0.0.54
> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
> ECDSA key fingerprint is
> SHA256:Y1P8iElhTm+EuI2BXVjlXAAIUMznx/kMZzAF+Nqdxeo. Are you sure you want
> to continue connecting (yes/no)? yes Warning: Permanently added
> '10.0.0.54' (ECDSA) to the list of known hosts. joerg@10.0.0.54's
> password:

Also. _DAS_ hätte ich da nicht gemacht. Da hätte ich dann schon erstmal mit
einem separaten System an dem Ding nachgeschaut, was da los sein kann. BTW,
hattest Du nicht geschrieben, das Ding liefe von einem USB-Stick? Hast Du
das Original-System von dem nch wo? Das hätte ich in dem Fall dann einfach
ersatzweise eingesteckt.
Die Frage hier ist dann durchaus "ist das jetzt noch _(m|D)ein_ System?"

ssh-Schlüssel verändern sich schließlich nicht ohne äußeres Zutun, sie
sollten das auch bei einem _regulären_ extern angestoßenen Update nicht
tun. Wenn sie das tun, ist - IMHO - Mißtrauen angebracht, das es erstmal
auszuräumen gilt.

> >> Wolf. Nervig ist, dass auch nach Absturz die gruene "Alles paletti"
> >> Betriebs-LED leuchtet, obwohl das Dingen voll festgefroren ist.  
...
> Nee, sie blinkt und geht erst dann auf Dauerlicht, wenn der Pogoplug 
> sich im LAN als verfuegbar meldet.

Schlecht implementiert. Es wäre besser, wenn sie bei einem erkannten
Fehler, oder evtl. auch beim Anmelden, "hektisch" (mit hoher Frequenz)
blinkt und im Normalbetrieb dann "beruhigend" (langsam) weiterblinkt.
Dann hat man bei Dauerleuchten oder -nichtleuchten sofort einen Indikator,
daß da was hängt. Hab' ich hier an einem Platinchen, das ein paar Daten
sammelt, so gemacht.

> Ich habe das ganz dekadent so wie in der Distro gelassen und weiss 
> nicht, wie diese LED software-maessig beschickt wird.

Dürfte mit einem kleinen Scriptchen einfach bedienbar sein, vielleicht
gibt's dafür sogar einen Treiber dafür oder einen /sys-File, der die
schaltet. Sowas wird gerne per "GPIO" (General Purpose In-Output) gemacht.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#115783

Sieghard Schicktanz <Sieghard.Schicktanz@schs.de> wrote:
> Hallo Joerg,
>> $ ssh 10.0.0.54
>> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
>> ECDSA key fingerprint is
>> SHA256:Y1P8iElhTm+EuI2BXVjlXAAIUMznx/kMZzAF+Nqdxeo. Are you sure you want
>> to continue connecting (yes/no)? yes Warning: Permanently added
>> '10.0.0.54' (ECDSA) to the list of known hosts. joerg@10.0.0.54's
>> password:
[...]
> ssh-Schlüssel verändern sich schließlich nicht ohne äußeres Zutun, sie
> sollten das auch bei einem _regulären_ extern angestoßenen Update nicht
> tun. Wenn sie das tun, ist - IMHO - Mißtrauen angebracht, das es erstmal
> auszuräumen gilt.

IP Adressen ändern sich aber manchmal. (Wenn sich der Schlüssel zur
gleichen IP ändert, kommt eine schärfere Warnung und keine ja/nein
Abfrage mehr, IIRC.)

Dass Joergs Netzwerk zwischen wackelig und komisch ist, wissen wir schon.

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

#115817

Hallo Enrik,

Du schriebst am Thu, 18 Mar 2021 22:25:41 -0000 (UTC):

> >> $ ssh 10.0.0.54
> >> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
> >> ECDSA key fingerprint is
...
> > ssh-Schlüssel verändern sich schließlich nicht ohne äußeres Zutun, sie
...
> IP Adressen ändern sich aber manchmal. (Wenn sich der Schlüssel zur

Dann kriegt man aber keine Verbindung zur alten Adresse, und die hat er ja
als Zielangabe benutzt -> Adresse muß unverändert geblieben sein.

> gleichen IP ändert, kommt eine schärfere Warnung und keine ja/nein
> Abfrage mehr, IIRC.)

Die angeführte Abfrage kommt, wenn sich der Maschinen- (Server-) schlüssel
geändert hat. Also muß sich wohl der Schlüssel geändert haben.
Ändert sich ein solcher gerne mal "von selber"?
Ändert er sich normalerweise bei einer Aktualisierung?
Nachdem ich _hier_, für _mich_ (und meine Kisten) das beides verneinen
kann, wäre _ich_ halt in einem solchen Fall mißtrauisch.
Solche Anfragen kenn ich aber durchaus, und zwar dann, wenn z.B. ein
RaspberryPi eine andere Systemkarte kriegt und wieder angeschlossen wird.
Damit hat dann einen anderen Maschinenschlüssel, aber die Hardware- (MAC-)
Adresse hat sich aufgrund derselben Karte nicht geändert und er kriegt dzf.
vom Nameserver dieselbe IP-Adresse.

> Dass Joergs Netzwerk zwischen wackelig und komisch ist, wissen wir schon.

Das ist aber kein Grund für wacklige (ssh-) Schlüssel. IMHO.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#115835

Sieghard Schicktanz <Sieghard.Schicktanz@schs.de> wrote:
> Hallo Enrik,
> 
> Du schriebst am Thu, 18 Mar 2021 22:25:41 -0000 (UTC):
> 
>> >> $ ssh 10.0.0.54
>> >> The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
>> >> ECDSA key fingerprint is
> ...
>> > ssh-Schlüssel verändern sich schließlich nicht ohne äußeres Zutun, sie
> ...
>> IP Adressen ändern sich aber manchmal. (Wenn sich der Schlüssel zur
> 
> Dann kriegt man aber keine Verbindung zur alten Adresse, und die hat er ja
> als Zielangabe benutzt -> Adresse muß unverändert geblieben sein.

Das stimmt natürlich; da habe ich nicht genau gelesen.

>> gleichen IP ändert, kommt eine schärfere Warnung und keine ja/nein
>> Abfrage mehr, IIRC.)
> 
> Die angeführte Abfrage kommt, wenn sich der Maschinen- (Server-) schlüssel
> geändert hat. Also muß sich wohl der Schlüssel geändert haben.

"can't be established" kommt, wenn der Schlüssel zur IP unbekannt ist.
Wenn er sich geändert hat, sieht das so aus:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

(In diesem Fall war es von mir erwartet gewesen.)

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

#115848

Hallo Enrik,

Du schriebst am Sat, 20 Mar 2021 11:22:03 -0000 (UTC):

> "can't be established" kommt, wenn der Schlüssel zur IP unbekannt ist.
> Wenn er sich geändert hat, sieht das so aus:
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle
> attack)! It is also possible that a host key has just been changed.
> 
> (In diesem Fall war es von mir erwartet gewesen.)

Ja, die Meldung kenne ich auch. Ich weiß (wußte) halt nicht genau, welche
Umstände die provozieren, obwohl ich schon öfters mal die eine oder andere
Maschine (auch "RasPi"s) mit unterschiedlichen Systemen benutze. Bisher
wenigstens habe ich die Meldung allerdings nie ohne bekannte Unterschiede
zum vorherigen Zustand erhalten.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#115794

Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
>> Es ist ArchLinux, es hat keine cron Eintraege in /etc und es kennt das 
>> Command crontab nicht. Muss man m.W. nachinstallieren (cronie?).
>
>Heißt der nicht "chrony"? Aber egal, einen cron-deamon hat Arch sicher
>auch, und wenn's der intern-integrierte systemd-eigene eingebaute Dienst
>ist. Der läuft dann natürlich nach systemd-internen eigenen Regeln...

cronie ist ein als drop-in-Ersatz zum klassischen crond gedacht; die
Red Hat Welt hat diese Migration schon erledigt. Die Debian-Welt noch
nicht (weil das hier wie so oft an einem einzigen Freiwilligen hängt,
der auch noch andere Dinge zu tun hat).

chrony ist ein ntp-Daemon, mit dem man den ntpd ersetzen könnte. Das
kann sich jeder für sich selbst entscheiden, da ntp nicht so tief im
System verankert wie ein crond.

systemd timer sind nochmal eine andere Baustelle; dass die den
klassischen crond irgendwann mal verdrängen ist unlikely.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

#115819

Hallo Marc,

Du schriebst am Fri, 19 Mar 2021 12:17:44 +0100:

[cronie]
> >Heißt der nicht "chrony"? Aber egal, einen cron-deamon hat Arch sicher
...
> cronie ist ein als drop-in-Ersatz zum klassischen crond gedacht; die

Aha, kannte ich noch nicht. Hat der Vorteile gegenüber den alten?

> chrony ist ein ntp-Daemon, mit dem man den ntpd ersetzen könnte. Das

Ok, das habe ich dann verwechselt aufgrund der Namensähnlichkeit.

> systemd timer sind nochmal eine andere Baustelle; dass die den
> klassischen crond irgendwann mal verdrängen ist unlikely.

Never say never... ?

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#115742

On Wed, 17 Mar 2021 22:22:58 +0100, Kay Martinen wrote:
>
> Am 17.03.21 um 21:16 schrieb Joerg:
>> On 3/16/21 11:24 PM, Jan Novak wrote:
>
>> vereinzelt unaufgeforderte Re-Boots stehen, doch da sucht man sich einen
>
> cronjob, unattended-updates?

Die rebooten ungefragt? Nun ja, man könnte crontab sagen, alle X Minuten
zu rebooten... Aber dass unattended-updates so einfach neu Booten...?

[...]

>> Bei der sich gelegentlich von selbst einschaltenden Schreibtischlampe
>> meiner Frau habe ich es raus. Wenn ich auf bestimmten Frequenzen im 40m
>> Band sende, geht die an.
>
> Vagabundierende HF? Antenne nicht geerdet? Vielleicht killt das auch
> deinen Pogoplug. Bei einem raspi-modell reicht eine Blitzlampe. ;-)

Das nennt man Fernbedienung. ;-)
-- 
Andreas

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

#115763 — Reboot-Verhalten unattended-upgrades (was: wlan hängt (manchmal))

Andreas Kohlbach <ank@spamfence.net> wrote:
> Die rebooten ungefragt? Nun ja, man könnte crontab sagen, alle X Minuten
> zu rebooten... Aber dass unattended-updates so einfach neu Booten...?

Mit diesen Einstellungen in /etc/apt/apt.conf.d/50unattended-upgrades
tut unattended-upgrades genau das:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

Inwieweit diese Einstellungen sinnvoll sind, muss jeder Admin für sich
selbst entscheiden. Immerhin kann man mit

Unattended-Upgrade::Automatic-Reboot-Time "02:00";

den Zeitpunkt des Neustarts festlegen.

Thomas Stein

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web