Dev July 2016

dev@lists.ffnw.de

19 participants
23 discussions

by lrnzo

Hallo, in unserer site.conf steht ja derzeit folgendes: next_node = { ip4 = '10.18.0.127', ip6 = 'fd74:fdaa:9dc4:127', mac = '16:41:95:40:f7:dc', }, und in der site.mk taucht auch eine Zeile mit gluon-next-node auf. Eigentlich sollte das betreffende Interface local-node@br-client also die passenden Adressen enthalten. In der Realität hat man aber nach Eingabe von 'ip a s' nur das hier: 10: local-node@br-client: mtu 1500 qdisc noqueue link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:… [View More]

8 years, 1 month

Puppet Entwicklungsworkflow

by Bjoern Franke

Moin, die momentane Situation bezüglich unseres Puppet-Entwicklungsworkflows stößt mir (und vermutlich auch anderen) etwas auf. Wie sieht der momentane Weg aus, um im unseren Puppet was zu entwickeln? - Auf dem Master im Production entwickeln - auf seinen Client kopieren - im git committen Wait, what? Warum machen wir das nicht "the bytemine way"? Ein dev-Branch, da entwickeln (und testen), dann per git commit ins production- Environment? Grüße bjo

8 years, 8 months

[patch master] fix patching error by emty build_patches dir

by Jan-Tarek Butt

Signed-off-by: Jan-Tarek Butt <tarek(a)ring0.de> --- buildscript | 2 ++ 1 file changed, 2 insertions(+) diff --git a/buildscript b/buildscript index ae75027..53985c4 100755 --- a/buildscript +++ b/buildscript @@ -122,9 +122,11 @@ get_source() { } patch_target() { + if test "$(ls -A "$PWD""/build_patches/openwrt/")"; then for patch in "$PWD"/build_patches/openwrt/*.patch; do patch --no-backup-if-mismatch -p0 -d "$target" -i "$patch" done + fi } prepare() { -- 2.9.0

8 years, 8 months

Nächste Firmware

by Jan-Tarek Butt

Hoi, der Milestone v1.1.1 ist gestern fertig geworden. Zudem ist der Milestone v1.2 auch schon zu annähend 50% fertig gestellt. Wenn niemand was dagegen hat, würde ich v1.1.1 überspringen und direkt v1.2 für einen signed request fertig machen sobald der dazugehörige Milestone fertig ist. Eike arbeitet gerade an der Abstraktion des geolocators issue #22 und ich überlege mir ein Protokolldesign für das mesh on LAN/WAN Management #63. vg Tarek

8 years, 8 months

hoodselector mesh on LAN/WAN Management

by Jan-Tarek Butt

Hi, Wie ich in der Mail "Lösung des Hood vs. Kabelmesh Problems" erwähnt hatte. Der neue thread zur möglichen Lösung des mesh on LAN/WAN Problems mit dem hoodselector. Die Idee wäre auf ein separates Protokoll auszuweichen welches aushandelt ob ein mesh Konflikt besteht. Dazu könnte man per respondd checken, ob auf dem mesh-on-wan/lan eine andere Hood läuft und gegebenenfalls das betroffene Interface aus der batman-adv bridge entfernen. Sobald keine fremden hoods mehr das sind könntem die … [View More]

8 years, 8 months

Lösung des Hood vs. Kabelmesh Problems

by Simon Kurka

Hallöle, mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft. Ich habe es noch nicht zu Ende gedacht!! Stichwort VLAN. Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird? Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden. Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhä… [View More]

8 years, 8 months

Hoodübergreifendes Routing

by Jan-Tarek Butt

> das Hoodübergreifende Routing zwischen den neuen Servern funktioniert auch problemlos. > > Das einzigste was derzeit noch nicht geht: Aus der Hood in das Altnetz. Das würde ich mir.die Tage mit Simon einmal zusammen anschauen. > > Aber ich denke der Hoodinterne Traffic ist erstmal wichtiger ;) Sehr gut :) danke dir vg Tarek

8 years, 8 months

Hoodübergreifendes Routing

by Stefan

Moin zusammen, das Hoodübergreifende Routing zwischen den neuen Servern funktioniert auch problemlos. Das einzigste was derzeit noch nicht geht: Aus der Hood in das Altnetz. Das würde ich mir.die Tage mit Simon einmal zusammen anschauen. Aber ich denke der Hoodinterne Traffic ist erstmal wichtiger ;) -- vg Stefan

8 years, 8 months

[master and v2016.1.x] add autoupdater upgrade.d script to drop batman-adv routing tables befor sysupgrade #821

by Jan-Tarek Butt

--- .../usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100755 package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables diff --git a/package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables b/package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables new file mode 100755 index 0000000..e931a0e --- /dev/null +++ … [View More]

8 years, 8 months

[master] add second drop caches after downloarding Firmware image

by Jan-Tarek Butt

--- admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches | 4 ++++ 1 file changed, 4 insertions(+) create mode 100755 admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches diff --git a/admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches b/admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches new file mode 100755 index 0000000..814159f --- /dev/null +++ b/admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches @@ -0,0 +1,4 … [View More]

8 years, 8 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev July 2016