Autoupdater in unterschiedlichen Rhein-Sieg-Domains (was: Frage zu Autoupdate)


#1

Hier in Meckenheim gibt es einige Knoten die sich nicht updaten obwohl autoupdate eingestellt ist. Ist da etwas zu beachten oder noch zu tuen?

z.b.
https://map.freifunk-rhein-sieg.de/#!v:m;n:60e3274a7c34
https://map.freifunk-rhein-sieg.de/#!n:c4e984f9bbcd


#2

Hi,

das ist ein bekannter Bug im Gluon. Manchmal stürzt der Autoupdater ab. Dann muss der Knoten leider einmal per Hand neu gestartet werden (oder per SSH sofern ein Schlüssel eingespielt worden war).

Grüße
Matthias


#3

hm. wann läuft denn das update? Beiden genannten Knoten wurden neu gestartet und leider immer noch kein Update

Gruß
Hagen


#4

Eigentlich läuft der kontinuierlich. Die Knoten fragen in der Regel einmal pro Stunde nach einer neuen Version und installieren diese dann innerhalb von 2-3 Tagen, wenn sie frisch verfügbar ist. Bei älteren Updates wird das Update sofort eingespielt.

Ist denn eine neuere Version verfügbar? Kommst du per SSH dauf und kannst mal die Ausgabe von

autoupdater

zeigen?

Viele Grüße
Matthias


#5

Also es gibt hier in Meckenheim Knoten mit stable-2.6 und die beiden genannten Knoten haben stable-2.5 / gluon-v2016.2.2 und stable-2.4.1 / gluon-v2016.2.1. Per SSH kann ich leider nicht auf die Knoten kommen


#6

Hallo Hagen,

Das autoupdate ist im Moment deaktiviert. Ich kann noch nicht sagen wann ich die Zeit finde das wieder hinzubiegen.

Grüße Stefan


#7

ah, dann hab ich ja nichts verkehrt gemacht. danke für die Info.


#8

Diesen Bug kenne ich nicht. Hast Du mal einen Github/Issue-Link dazu?


#9

Ich habe mich im Detail auch nicht damit beschäftigt. Hatte das mal angefragt, scheint wohl in der aktuellen Version erledigt zu sein: Autoupdater läuft als Zombie · Issue #1212 · freifunk-gluon/gluon · GitHub


#10

Gibt es hier schon neue Informationen wie es mit dem Update der Router weitergehen soll?


#11

Wenn gar nix will, dann müsste es zumindest auf einem Knoten per ssh-Login gebugt werden.
Die Möglichkeiten, warum ein Autoupdate nicht ausgeführt wird.
(am besten wirklcih auf der Console schauen.)


#12

ich bin verwirrt. Die letzte Aussage von Stefan war das der Autoupdate garnicht geht.

Ist das immer noch so? Oder geht er wieder und wir müssen jetzt das Problem auf den Nodes fixen?

Gruß
Hagen


#13

Das war im August 2017.

Schau mal hier:


(Das klingt für mich auch nach “Rhein Sieg”. Oder gibt es da mehrere Domains diesen Namens?)


#14

Hallo Hagen,

wir bekommen auf jeden fall ein Autoupdate hin. Wie ich aber gerade gesehen habe wurde das ursprüngliche Site Git gelöscht bzw. ersetzt. Ich gehe mal auf die suche wieso und kümmere mich darum, das in den nächsten tagen ein Update gebaut wird.

Grüße

Stefan


#15

Hallo Stefan, ich danke dir für die Antwort. Das wäre wirklich cool. Ich wollte morgen auf meinem Router mal per ssh prüfen ob ich da eine Fehlermeldung finde. Aber wie gesagt es sind alle Meckenheimer Router betroffen und da glaube ich nicht das es ein individuelles Problem ist.

@adorfer Für mich bedeutet die Meldung das es eine neue Version gibt nicht gleichzeitig das das autoupdate gefixt. ist.

Gruß Hagen


#16

Wie per PN geschrieben, müsst ihr über ein 2016.2.6 gehen um auf 2017.1.x zu kommen.


#17

Ist das Rhein Sieg spezifisch und weist du den Grund, für ein Zwischenupdate? Zumindest, wenn im Knoten nichts individuell verstellt wurde, wüsste ich jetzt keinen generellen Grund.

LG Stefan


#18

RTFM. :wink: Die Begründung habe ich zwar auch nicht verstanden, aber dort steht es:
http://gluon.readthedocs.io/en/v2017.1.x/releases/v2016.2.6.html


#19

Selber RTFM!

Waren das da oben etwa Futros oder andere x86/x64-Geräte?
Nur diese brauchen unbedingt das Zwischenupdate, weil anders nicht gewährleistet ist, dass das Partitionslayout des Images rechtzeitig vergrößert wird vorm finalen Update auf LEDE?


#20

Hallo Stephan,

auf github habe ich keine site.conf für Meckenheim gefunden. Da die (noch) verfügbaren aber ähnlich sein sollten, hier ein paar Anmerkungen zu

https://github.com/Freifunk-Rhein-Sieg/ffrsk-site/blob/v2016_2.x_Altenkirchen/site.conf:

opkg_repo = ‘http://downloads.openwrt.org/chaos_calmer/15.05.1/%S/packages’,

Wird nicht funktionieren, weil

  • die DNS Auflösung nicht funktioniert,
  • die speziell mit dem Release gebauten Module im - Verzeichnis packages in output - genutzt werden müssen. Der Kernel Gluon ist nicht kompatibel mit dem normalen openwrt / LEDE.
    Dies ist aber nur wichtig, wenn man Module auf eienm Router selbst nachinstallieren will. Diese Änderungen gehen jedoch mit Update verloren.

ntp_servers = { ‘2a03:2260:3017:1100::2’, ‘1.de.pool.ntp.org’, ‘2.de.pool.ntp.org’, ‘3.de.pool.ntp.org’ },

Funktioniert nicht, weil

  • es den Server 2a03:2260:3017:1100::2 scheinbar nicht gibt,
  • die DNS Auflösung der anderen Server nicht funktioniert.

Lösung: Einen eigenen Router zum Zeitserver machen oder IPV6 Adressen angeben. Feste Adressen sind blöde , aber die DNS Einstellungen auch.

mirrors = {
http://firmware.ffsu/altenkirchen/stable/sysupgrade’,
http://firmware.freifunk-rhein-sieg.net/altenkirchen/stable/sysupgrade’,
‘http://[2a03:2260:3017:100::2]/altenkirchen/stable/sysupgrade’,

Funktioniert nicht, weil

  • DNS nicht funktioniert,
  • [2a03:2260:3017:100::2] nicht existiert.

Lösung: Der Server [2a03:2260:3017:100::2] muss wieder in Betrieb. Nur von ihm können Update gezogen werden, wenn kein Root-Zugang eingerichtet ist und man nicht jeden Router neu installieren will.

Der Autouploader funktioniert richtig, wenn auch die Zeitserver funktionieren. Andernfalls hängt der Router über Tage oder Monate hinter der tatsächlichen Zeit udn der Autouploader nimmt die Updates schon beim ersten Versuch. Wäre nicht schlimm, aber wenn alle Knoten gleichzeitig eine Aktualisierung wünschen, wird die Last erheblich.