root@uemit:/etc/xen/hosts# Error: (2, ‚Invalid kernel‘, ‚elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images‘)
Ich habe dann noch dieses hier gefunden aus einem älteren Mailinglistenarchiv, könnte aber outdated sein:
When you execute make menuconfig, choose Target=x86 and SubTarget=„Xen
paravirt Guest“. Then go to Kernel Modules → Virtualisation Support
Xen PCI frontend is disabled by default. Did you activated it ?
sonst noch jemand Anleitungen sich einen VPN Offloader selbst zu bauen?
Wäre ja nur von Interesse für das FF Projekt…
Auf den Routern ist fastd ja schon korrekt eingerichtet.
Man müsste es nur auf eine andere Maschine portieren können…
die config von fastd könnte man sich doch schonmal ziehen…
Im Grunde ist es nicht schwierig.
Man könnte hier eine quasi schlüsselfertige Lösung über Ansible anbieten, die mit wenig Vorarbeiten ein nacktes Linux seiner Wahl mit den entsprechenden Paketen und Konfigurationsdateien bestückt. @nomaster hat am Samstag zum Ansible Meetup im Chaosdorf geladen. Ich werde dort sein. Vielleicht können wir das dann exemplarisch mal durchexerzieren.
Meinen eigenen Mailserver verwalte ich bereits mit Ansible und habe da also Erfahrungen, die ich gerne mit anderen teile.
Edit: Mir fällt auf, die Veranstaltung wird nicht von @nomaster ausgerichtet, er war es nur der mich darauf hinwies
ich denke auch, dass es nicht schwierig ist.
Wäre super wenn wir irgendwann eine einheitliche Anleitung für die entpr. Distributionen und Domänen hinbekämen.
Wenn ich z.B. für den Ausbau von Kirchtürmen o.ä. verantwortlich bin und gerade keine zweite technische Hand zur Seite habe, wäre das auf jeden Fall von Vorteil um sowas mehrwertig aufzuziehen.
Es geht darum von anderen unabhängig zu sein und auch um persönliche Kontakte zu entlasten.
Deshalb ist mir persönlich die Dokumentation sehr wichtig.
Wäre super wenn du das mal anschneiden könntest bei eurem Meetup!
Man kann vermutlich ausm fastd wesentlich mehr Performance rausholen, ich habe aufm letzten CCC Kongress mitm neoraider (Entwickler von fastd) gemessen, und wir kamen grad mal auf 12% CPU für fastd (inkl. verschlüsselung, usw.). Der Rest, 88%, geht im Kernel verloren, vermutlich wegen den Kontextswitchen. Die tun/tap Schnittstelle ist so definiert, dass man pro Paket, das maximal 1500 Byte groß sein kann, einmal gelesen und einmal geschrieben werden muß. Hierfür wird vom Usermode in den Kernelmode gewechselt, was man Kontextswitch nennt. Bei 100 Mbit/sek wären das mindestens 16.777 Kontextswitche pro Sekunde, und das ist einfach zu viel für so ne kleine Box.
Da mir allerdings auch keiner helfen wollte, wo ich hilfe mit dem Förderverein gebraucht hätte, darf sich das jemand anders weiter anschauen und ggf. optimieren.
Also konkretes zur Anleitung gibt es ja irgendwie nur durch Zusammengesuche (ist mir bekannt, mach ich gerne, bin ich gewohnt…), Dann gibt es wiederum spezielle Konfigurationen für die Domänen. Ein Update ist aber so wie ich das sehe regelmäßig nicht notwendig? Zumindest nicht wenn es sich um Debian o.ä. handelt bzw sich die Konfigurationen der Supernodes nicht ändern…
Ich bin vielleicht am spinnen aber ich stelle mir vor, dass man in enger Zusammenarbeit mit ein paar Leutchen ein Fastd-Server konfiguriert und dann ein bzw. mehrere images davon (für alle Domänen) zur Verfügung stellt, für Geräte wie BananaPi o.ä.
Die Einplatinencomputer wie RaspberryPi oder BananaPi genießen den Komfort das Betriebssystem recht komplikationslos mittels SD Karte auszutauschen.
Non-Techie User, die mehr machen wollen als nur Router aufstellen, könnten sich dann das image für einen FastD Server (von uns erstellt) laden, auf SD Karte kopieren und dann in einen BananaPi stecken → Plug-and-Play halt.
Für u.a. diese Zielgruppe wäre es dann nämlich recht einfach eine VPN Rechenmaschine ohne viel Handarbeit aufzusetzen.
Ich muss mich in der Beziehung leider mäßig geschlagen geben, da mein Netzwerk-Konfigurationsverständnis nicht allzuweit reicht. Debian, die Shell, grundsätzliches Arbeiten mit Linux jedoch kein Problem für mich.
Meine Frage: Gibt es Freiwillige, damit wir im etwas direkterem Kontakt (IRC, Mumble) sowas auf die Beine stellen könnten? Bestimmt gibt es dann auch noch viele Optimierungen die getätigt werden müssen.
Finde ich eine super Idee. Brauch man hierfür aber nicht eine Feste IP?
Vielleicht habe ich das System mit den Supernodes falsch verstanden (bitte dann um Aufklärung). Das sind die Server, zu den das VPN von den einzelnen Nodes aufgebaut werden und dann bei manchen Communitys ins Ausland ein VPN aufbauen?
Ich sag mal so, geringfügige Anpassungen kann man evtl. noch als kleine Installationsanleitung mit an die Hand geben: Nur dass das grundsätzliche schonmal gemacht ist…
Zum Supernode:
Ins Ausland wird, meines Wissens nach, nicht mehr umgeleitet da der Verein ende des Jahres '14 Providerstatus erlangt hat und die Störerhaftung für diesen rausfällt.
Nein hier geht es nur um etablierung einer VPN Verbindung. Jeder Router leistet im Moment Rechenarbeit für die VPN Verschlüsselung. Damit dieser entlastet wird, kann man diese Rechenarbeit auch auslagern: Z.B. auf leistungsstärkere Maschinen, damit mehr Durchsatz möglich ist.
Bitte bedenkt aber, dass das Autoupdate z.B. im Rheinufer der Rettungsanker war, die Domain überhaupt wieder ans Laufen zu bekommen vorletzte Woche.
Erst „IPv6 komplett aus“, Autoupdate 36h lang abwarten lassen, damit mindestens 95% der Nodes auf neuer SW sind (mit einigen Workarounds wie „weg mit den ULA-IPs, kein NTP, kein Autodupdate-Server im lokalen Mesh“).
Wenn da haufenweise unabhängige Nodes gestanden hätten, dann wäre das noch viel schmerzhafter geworden, weil dann manuell noch Updates auf in Haufen Bananapis hätte ausgerollt werden müssen.
Funktionsfähige Kontaktadressen sollten also für solche Nodes selbstverständlich sein. Und wir sollten über einen externen (signaturgesicherten…) Killswitch nachdenken.
Mich würde erstmal das How-To an sich interessieren. Dann kann man immer noch abwägen ob das integrierbar genug wäre oder nicht. Bis dahin: reines interesse an der Technik.
Die Gluon Jungs waren jetzt nicht so hot auf einen an OpenWrt trunk entlangeführten Gluon branch. Aber ich hatte Bock
Laufen tut das Ganze noch nicht (bootet, aber Netzwerk kommt nicht hoch), da noch einige deprecated Lua APIs verwendet werden. Da bin ich gerade dran. Hier lokal hab ich’s teilweise schon laufen. Komme auf jeden Fall an den Config Mode.
Da bin ich noch nicht. Erstmal muss ich die vorhandenen Pakete soweit auf dem neuen OpenWrt Branch zum laufen bringen. Dann kann ich neue Targets einfügen.
Ich dachte nur ich meld mich mal frühzeitig, damit man keine Arbeit dupliziert. Aber OpenWrt trunk hat ja bereits support für’s BananaPi. Daher sollte das nicht mehr so arg schwierig werden.
Wie würdest du das denn dann mit den Netzwerkkarten machen? Man hat ja nur 1x Ethernet. VLANs und dann per Switch oder per USB ne weitere Ethernet Buchse dran? Da wäre natürlich die Frage ob das performt.
