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
--
Kai Sommer | http://sok.ai
Schopenhauerstraße 29 | http://ka.i-sommer.de
14467 Potsdam | xmpp: me(a)sok.ai
sig: CB0E 7DC5 5F32 456A 94A4 | pubkey: http://ma.ximi.se/mekey
Tach zusammen …
Gerade habe ich mal (inspiriert durch den letzten Edit im Wiki auf der
Seite „StatusUpdates“) das ab Backfire verwendete Init-Skript „ffp-apdb“
etwas aufgefrischt … :)
Hinzu gekommen ist (haupts.) die automatische Erkennung des
wifi-Interfaces (10.22.X.X), damit das nicht mehr manuell im Skript
rumgemurkst werden muss.
(Außerdem gabs ne Unschönheit bei der uptime-Ermittlung, die nun auch
korr. ist.)
→ Bei mir (2-160-sokai) läufts korrekt …
FYI: Ich hoste das Skript (ganz) simpel bei GitLab [0].
(Commits/Änderungen können hier [1] nachgeschaut werden …)
[0] <https://gitlab.com/FFP/ffp-apdb-client/>
[1] <https://gitlab.com/FFP/ffp-apdb-client/commits/master/>
Wer Fehler findet, melde sie bitte!
Und wer ggf. mitwerkeln will, klickt sich nen GitLab-Account und dann
kann ich sie/ihn (nach Meldung) der GitLab-Gruppe hinzufügen … :)
So weit von mir. – Grüße
der Kai
PS:
Wiki-Seite [2] habe ich schon den Neuerungen entsprechend angepasst …
[2] <http://wiki.freifunk-potsdam.de/StatusUpdates>
--
Kai Sommer | http://sok.ai
Schopenhauerstraße 29 | http://ka.i-sommer.de
14467 Potsdam | xmpp: me(a)sok.ai
sig: CB0E 7DC5 5F32 456A 94A4 | pubkey: http://ma.ximi.se/mekey
Tach zusammen …
FYI:
Beim Basteln in den letzten Tagen habe ich mir auch mal unsere APDB
[0] (wieder) vorgenommen …
[0] <http://freifunk-potsdam.de/apdb/>
# behind the scenes
- alle ext. Bibliotheken sind auf dem aktuellen (stable) Stand
# Neuerungen
## allgemein
- Filter/Suche (oben rechts) allgemein: Phrasen können gefiltert/-sucht
werden, wenn sie in Hochkommata eingeschlossen werden
## Spalten
a) Spalte „Firmware“
- hier habe ich ein „v “ vor den String gesetzt, damit der Filter besser
funktioniert
b) Spalte „Status“
- neue (letzte) Spalte
- ist unsichtbar in der Datatable-Ansicht
- enthält Online|Offline
# Beispiele zum Filtern in den Spalten
## a)
- "v 0.1.1" (_mit_ Hochkommata) = filtert alle APs, die die
Firmwareversion 0.1.1 haben
## b)
- online = zeigt alle APs an, die online sind
- offline = zeigt alle APs an, die offline sind
… viel Freude und Grüße
der Kai
--
Kai Sommer | http://sok.ai
Schopenhauerstraße 29 | http://ka.i-sommer.de
14467 Potsdam | xmpp: me(a)sok.ai
sig: CB0E 7DC5 5F32 456A 94A4 | pubkey: http://ma.ximi.se/mekey
Hi @all und vor allem alt Eingesessenen,
durch das ganze aktualisieren fällt mir die ganz Zeit das alte Zeug auf die Füß.
* Kann im Portal Technik[1] die Retroecke raus oder auf eine eigene Seite ausgelagert werden?
* Kann auf der Seite Freifunkhardware[2] Backfire und White Russian raus?
===
* Roaming wurde komplett auf eine eigene Seite[3] ausgelagert (in Entwicklung).
* Anleitung zu Kathleen wurde aktualisiert, da noch Fehler drinn waren. SGW und ffp-apdb wieder hinzugefügt.
Gruß
Carsten
[1] http://wiki.freifunk-potsdam.de/Portal:Technik
[2] http://wiki.freifunk-potsdam.de/Freifunkhardware
[3] http://wiki.freifunk-potsdam.de/Roaming
Ho @ all,
unter den alten IP-Einträgen[1] sind ganz viele Eintragungen mit dem Status Test|Reserviert|Offline|Aufbau, was durch die neuen IP-Adressen hinfällig ist.
Könnt ihr / Können wir die Einträge löschen?
Gruß
Carsten
[1] http://wiki.freifunk-potsdam.de/IP-Adressen#vergebene_IP-Adressen
Hallo,
Euch zur Info, ich habe einen WR841N v.10 mit der unstable Kathleen 0.2.0 [1] geflasht und hier testweise am laufen.
Das flashen und einrichten verlief ohne Probleme. Wie stabil das ganze läuft werden wir sehen.
Gruß Bernd
[1] http://buildbot.berlin.freifunk.net/buildbot/unstable/ar71xx/751/default_4M…
Hi @all,
da ich jetzt schon öfter angesprochen wurde, dass die Bilder in der
Anleitung, aufgrund der neuen IPs, veraltet sind, habe ich sie jetzt
aktualisiert.
Kann bitte wer über die Anleitung schauen, ob Fehler drin sind. Hab auch
an einigen Stellen den Test korrigiert.
http://wiki.freifunk-potsdam.de/Kathleen
Danke
Gruß
Carsten
Hey @all!
Schon eine Weile stelle ich (un)regelmäßig fest, dass meine Nano
(2-160-sokai) rumzickt. – Dies ist an folgenden Dingen zu erkennen:
- die Uptime ist miserabel = mehrere Reboots pro Tag
- der Load ist nach 30mins zw. 1 und 2
- ich kann sie im lokalen Netz nicht per SSH erreichen (dann ziehe ich
meist mal kurz den Stecker)
- wenn ich mich durch (den Adminbereich des) LuCI klicke, bleibt die
Kiste iwann hängen (und ich muss den Stecker ziehen)
Nun habe ich die letzten Tage mal etwas geschaut und festgestellt, dass
ich – bspw. jetzt gerade – bei 37 Minuten uptime (schon) 53 DHCP-leases
habe.
Da ich ja direkt ggü. des Einstein-Gymnasiums bin, kommen die Clients
wahrsch. alle von da. (Nach 30mins habe ich auch schon 15MB übers
WAN/VPN geschliffen …)
→ Kann es also sein, dass meine Nano etwas überfordert ist? – Hat jmd.
Vergleichszahlen/Erfahrungen?
Und wenn ich mit meiner Vermutung richtig liege, was soll(te)/kann ich
eurer Meinung nach tun? (Ich hatte bspw. an ein Limit von max. 10
DHCP-leases gedacht …)
Danke schon mal und Grüße
der Kai
--
Kai Sommer | http://sok.ai
Schopenhauerstraße 29 | http://ka.i-sommer.de
14467 Potsdam | xmpp: me(a)sok.ai
sig: CB0E 7DC5 5F32 456A 94A4 | pubkey: http://ma.ximi.se/mekey
