Tach zusammen …
FYI: Beim Basteln am serverseitigen Kram für unsere APDB [0] habe ich auch das Client-/AP-Skript angefasst und ein paar Neuigkeiten dazu …
[0] http://freifunk-potsdam.de/apdb/
# Vorab a) Das Skript ist bei einer Bastelei von mir entstanden und nun ja schon eine Weile produktiv bei uns im Einsatz. – D.h. aber nicht, dass der Code gut/hübsch/… ist! (Für Verbesserungsvorschläge bin ich immer zu haben! :-))
b) Der Code bef. frei zugänglich in einem git-Repo bei GitLab [1] und damit sind auch alle Änderungen (iwie) einseh-/fndbar. – Wer Lust hat mitzumachen, klicke sich bitte nen GitLab-Account und gibt mir bzgl. einer Gruppen-Einladung Bescheid!
[1] https://gitlab.com/FFP/ffp-apdb-client
# Neues (Auszüge/das Wichtigste) 1. einige Kommandos wurden durch uci [2] ersetzt; da uci aber nicht alle Daten, die wir wollen, hat gibt es weiterhin auch noch nen paar alte 2. es gibt nun eine Upgrade-Funktion :) 3. bei der Installation wird für den Cron-Job nun eine Zufallszahl für die Minute, zu der das Update gesendet werden soll, generiert; das wird ggf. den Ansturm der APs zu immer der selben Zeit etwas verbessern
[2] https://wiki.openwrt.org/doc/uci
Zu 2. noch: Wie in der README [3] kurz beschrieben, reicht ab sofort ein einfacher Aufruf für das Skript-Upgrade. (Dieses könnte man auch iwie als Cron einrichten, dann wäre der AP immer mit der aktuellsten Version versorgt …) Leider muss zur Nutzung der Upgrade-Funktion jedoch erst einmal die neueste Version installiert sein. :-/
[3] https://gitlab.com/FFP/ffp-apdb-client#upgrade
Abschließend noch der Hinweis, dass die Installation nun auch etwas vereinfacht wurde. – Dazu mal im Abschnitt Installation [4] (in der README) schauen … :) ! Hinweis: Ein aktuell installiertes Skript wird dabei überschrieben. !
[4] https://gitlab.com/FFP/ffp-apdb-client#installation-at-access-point
Das also mal auf die Schnell von mir … – Viel Freude und Grüße der Kai
Hi Kai,
schöne Sache. Gefällt mir. Besonders die Upgradefunktion. Sehe ich es aber richtig, dass ich das Upgrade manuell ausführen muss? Wäre schön, wenn sich das Skript selbst aktualisiert. Oder spricht etwas dagegen?
So müssen wir jetzt 60 Knoten anfassen und das Skript aktualisieren und wenn es aktualisiert wird müssen wir nochmal 60 Knoten anfassen und upgrade eintippen.
Aber vielen Dank für deine Arbeit.
Gruß carsten
Am 22.01.2016 um 20:01 schrieb Kai Sommer:
Tach zusammen …
FYI: Beim Basteln am serverseitigen Kram für unsere APDB [0] habe ich auch das Client-/AP-Skript angefasst und ein paar Neuigkeiten dazu …
[0] http://freifunk-potsdam.de/apdb/
# Vorab a) Das Skript ist bei einer Bastelei von mir entstanden und nun ja schon eine Weile produktiv bei uns im Einsatz. – D.h. aber nicht, dass der Code gut/hübsch/… ist! (Für Verbesserungsvorschläge bin ich immer zu haben! :-))
b) Der Code bef. frei zugänglich in einem git-Repo bei GitLab [1] und damit sind auch alle Änderungen (iwie) einseh-/fndbar. – Wer Lust hat mitzumachen, klicke sich bitte nen GitLab-Account und gibt mir bzgl. einer Gruppen-Einladung Bescheid!
[1] https://gitlab.com/FFP/ffp-apdb-client
# Neues (Auszüge/das Wichtigste)
- einige Kommandos wurden durch uci [2] ersetzt; da uci aber nicht alle
Daten, die wir wollen, hat gibt es weiterhin auch noch nen paar alte 2. es gibt nun eine Upgrade-Funktion :) 3. bei der Installation wird für den Cron-Job nun eine Zufallszahl für die Minute, zu der das Update gesendet werden soll, generiert; das wird ggf. den Ansturm der APs zu immer der selben Zeit etwas verbessern
[2] https://wiki.openwrt.org/doc/uci
Zu 2. noch: Wie in der README [3] kurz beschrieben, reicht ab sofort ein einfacher Aufruf für das Skript-Upgrade. (Dieses könnte man auch iwie als Cron einrichten, dann wäre der AP immer mit der aktuellsten Version versorgt …) Leider muss zur Nutzung der Upgrade-Funktion jedoch erst einmal die neueste Version installiert sein. :-/
[3] https://gitlab.com/FFP/ffp-apdb-client#upgrade
Abschließend noch der Hinweis, dass die Installation nun auch etwas vereinfacht wurde. – Dazu mal im Abschnitt Installation [4] (in der README) schauen … :) ! Hinweis: Ein aktuell installiertes Skript wird dabei überschrieben. !
[4] https://gitlab.com/FFP/ffp-apdb-client#installation-at-access-point
Das also mal auf die Schnell von mir … – Viel Freude und Grüße der Kai
Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/listinfo/users
Hallo
wir haben das script ja grade auf dem router im kuze theater laufen, ich hab da folgende änderungen gemacht: zeile 24: CRONINTERVAL=$(head -30 /dev/urandom | tr -dc "012345" | head -c2) # run cron hourly at a random minute zeile 50: CRONJOB="${CRONINTERVAL} * * * * ${SCRIPT} update # FFP Access Points DataBase"
vorher hatte er oft intervalle größer 60 eingetragen und das "*/" brauchen wir ja nicht, wenn das script nur alle stunde läuft.
Sven
On 23.01.2016 11:26, Carsten N wrote:
Hi Kai,
schöne Sache. Gefällt mir. Besonders die Upgradefunktion. Sehe ich es aber richtig, dass ich das Upgrade manuell ausführen muss? Wäre schön, wenn sich das Skript selbst aktualisiert. Oder spricht etwas dagegen?
So müssen wir jetzt 60 Knoten anfassen und das Skript aktualisieren und wenn es aktualisiert wird müssen wir nochmal 60 Knoten anfassen und upgrade eintippen.
Aber vielen Dank für deine Arbeit.
Gruß carsten
Am 22.01.2016 um 20:01 schrieb Kai Sommer:
Tach zusammen …
FYI: Beim Basteln am serverseitigen Kram für unsere APDB [0] habe ich auch das Client-/AP-Skript angefasst und ein paar Neuigkeiten dazu …
[0] http://freifunk-potsdam.de/apdb/
# Vorab a) Das Skript ist bei einer Bastelei von mir entstanden und nun ja schon eine Weile produktiv bei uns im Einsatz. – D.h. aber nicht, dass der Code gut/hübsch/… ist! (Für Verbesserungsvorschläge bin ich immer zu haben! :-))
b) Der Code bef. frei zugänglich in einem git-Repo bei GitLab [1] und damit sind auch alle Änderungen (iwie) einseh-/fndbar. – Wer Lust hat mitzumachen, klicke sich bitte nen GitLab-Account und gibt mir bzgl. einer Gruppen-Einladung Bescheid!
[1] https://gitlab.com/FFP/ffp-apdb-client
# Neues (Auszüge/das Wichtigste)
- einige Kommandos wurden durch uci [2] ersetzt; da uci aber nicht alle
Daten, die wir wollen, hat gibt es weiterhin auch noch nen paar alte 2. es gibt nun eine Upgrade-Funktion :) 3. bei der Installation wird für den Cron-Job nun eine Zufallszahl für die Minute, zu der das Update gesendet werden soll, generiert; das wird ggf. den Ansturm der APs zu immer der selben Zeit etwas verbessern
[2] https://wiki.openwrt.org/doc/uci
Zu 2. noch: Wie in der README [3] kurz beschrieben, reicht ab sofort ein einfacher Aufruf für das Skript-Upgrade. (Dieses könnte man auch iwie als Cron einrichten, dann wäre der AP immer mit der aktuellsten Version versorgt …) Leider muss zur Nutzung der Upgrade-Funktion jedoch erst einmal die neueste Version installiert sein. :-/
[3] https://gitlab.com/FFP/ffp-apdb-client#upgrade
Abschließend noch der Hinweis, dass die Installation nun auch etwas vereinfacht wurde. – Dazu mal im Abschnitt Installation [4] (in der README) schauen … :) ! Hinweis: Ein aktuell installiertes Skript wird dabei überschrieben. !
[4] https://gitlab.com/FFP/ffp-apdb-client#installation-at-access-point
Das also mal auf die Schnell von mir … – Viel Freude und Grüße der Kai
noch besseren zufall: $(awk 'BEGIN{srand();print int(rand()*9)}')
On 31.01.2016 22:19, Sven wrote:
Hallo
wir haben das script ja grade auf dem router im kuze theater laufen, ich hab da folgende änderungen gemacht: zeile 24: CRONINTERVAL=$(head -30 /dev/urandom | tr -dc "012345" | head -c2) # run cron hourly at a random minute zeile 50: CRONJOB="${CRONINTERVAL} * * * * ${SCRIPT} update # FFP Access Points DataBase"
vorher hatte er oft intervalle größer 60 eingetragen und das "*/" brauchen wir ja nicht, wenn das script nur alle stunde läuft.
Sven
On 23.01.2016 11:26, Carsten N wrote:
Hi Kai,
schöne Sache. Gefällt mir. Besonders die Upgradefunktion. Sehe ich es aber richtig, dass ich das Upgrade manuell ausführen muss? Wäre schön, wenn sich das Skript selbst aktualisiert. Oder spricht etwas dagegen?
So müssen wir jetzt 60 Knoten anfassen und das Skript aktualisieren und wenn es aktualisiert wird müssen wir nochmal 60 Knoten anfassen und upgrade eintippen.
Aber vielen Dank für deine Arbeit.
Gruß carsten
Am 22.01.2016 um 20:01 schrieb Kai Sommer:
Tach zusammen …
FYI: Beim Basteln am serverseitigen Kram für unsere APDB [0] habe ich auch das Client-/AP-Skript angefasst und ein paar Neuigkeiten dazu …
[0] http://freifunk-potsdam.de/apdb/
# Vorab a) Das Skript ist bei einer Bastelei von mir entstanden und nun ja schon eine Weile produktiv bei uns im Einsatz. – D.h. aber nicht, dass der Code gut/hübsch/… ist! (Für Verbesserungsvorschläge bin ich immer zu haben! :-))
b) Der Code bef. frei zugänglich in einem git-Repo bei GitLab [1] und damit sind auch alle Änderungen (iwie) einseh-/fndbar. – Wer Lust hat mitzumachen, klicke sich bitte nen GitLab-Account und gibt mir bzgl. einer Gruppen-Einladung Bescheid!
[1] https://gitlab.com/FFP/ffp-apdb-client
# Neues (Auszüge/das Wichtigste)
- einige Kommandos wurden durch uci [2] ersetzt; da uci aber nicht
alle Daten, die wir wollen, hat gibt es weiterhin auch noch nen paar alte 2. es gibt nun eine Upgrade-Funktion :) 3. bei der Installation wird für den Cron-Job nun eine Zufallszahl für die Minute, zu der das Update gesendet werden soll, generiert; das wird ggf. den Ansturm der APs zu immer der selben Zeit etwas verbessern
[2] https://wiki.openwrt.org/doc/uci
Zu 2. noch: Wie in der README [3] kurz beschrieben, reicht ab sofort ein einfacher Aufruf für das Skript-Upgrade. (Dieses könnte man auch iwie als Cron einrichten, dann wäre der AP immer mit der aktuellsten Version versorgt …) Leider muss zur Nutzung der Upgrade-Funktion jedoch erst einmal die neueste Version installiert sein. :-/
[3] https://gitlab.com/FFP/ffp-apdb-client#upgrade
Abschließend noch der Hinweis, dass die Installation nun auch etwas vereinfacht wurde. – Dazu mal im Abschnitt Installation [4] (in der README) schauen … :) ! Hinweis: Ein aktuell installiertes Skript wird dabei überschrieben. !
[4] https://gitlab.com/FFP/ffp-apdb-client#installation-at-access-point
Das also mal auf die Schnell von mir … – Viel Freude und Grüße der Kai
Hi Sven,
danke für deine Vorschläge! (Den letzten hatte ich bereits umgesetzt …)
Am 02.02.2016 um 22:53 schrieb Sven:
noch besseren zufall:
Was meinst du mit „besser“? – Die Quali der Zufallswerte, wenn es das ist, ist bei Cron ja eher zweitrangig. Die Idee war nur, dass nicht alle APs zu einer einheitl. Minute den Cron ausführen …
$(awk 'BEGIN{srand();print int(rand()*9)}')
[…]
*hmmm* So produziert er bei mir nur einstellige Werte (0–9). – Hast du da am Ende vllt. ne 5 vergessen … ;) → "$(awk 'BEGIN{srand();print int(rand()*59)}')"
Weiß jetzt nicht, ob ich das ändern soll … – Ja, der Befehl ist kürzer, aber ist die Änderung ‚notwendig‘ … *grübel*
Grüße der Kai
besser, weil man genau angeben kann, aus welchem bereich man ne zufallszahl will.
"$(awk 'BEGIN{srand();print int(rand()*60)}')"
dann, um ne zufallszahl 0 <= x < 60 zu erhalten, rand() bibt immer einen wert kleiner 1 zurück.
das andere war ein fieser hack, vorher hat er auch zahlen größer 60 ausgespuckt, wo ich nicht weiß, was cron dann genau tut. der hack war, dass er nur die ziffern 0-5 benutzt, das heißt, dass er zum beispiel keine 46 oder 28 produzieren kann, außerdem gab es die möglichkeit, dass er auch mal gar keine zahl ausspuckt, wenn der zufall schlechte laune hat und in den 30 zufälligen zeichen mal keine zahl dabei ist.
also nicht bessere entropie, aber bessere verlässlichkeit, dass es immer funktioniert.
Sven
Am 03.02.2016 um 10:07 schrieb Kai Sommer:
Hi Sven,
danke für deine Vorschläge! (Den letzten hatte ich bereits umgesetzt …)
Am 02.02.2016 um 22:53 schrieb Sven:
noch besseren zufall:
Was meinst du mit „besser“? – Die Quali der Zufallswerte, wenn es das ist, ist bei Cron ja eher zweitrangig. Die Idee war nur, dass nicht alle APs zu einer einheitl. Minute den Cron ausführen …
$(awk 'BEGIN{srand();print int(rand()*9)}')
[…]
*hmmm* So produziert er bei mir nur einstellige Werte (0–9). – Hast du da am Ende vllt. ne 5 vergessen … ;) → "$(awk 'BEGIN{srand();print int(rand()*59)}')"
Weiß jetzt nicht, ob ich das ändern soll … – Ja, der Befehl ist kürzer, aber ist die Änderung ‚notwendig‘ … *grübel*
Grüße der Kai
participants (3)
-
Carsten N -
Kai Sommer -
Sven