[Fli4l_dev] chrony und VPN-Tunnels starten nicht auf Ethernet-Router

[Christoph Schulz]

Hallo!

Hans Bachner schrieb:

> Hmmm... wäre das die stable-Version, gäb's vielleicht einen Patch...

Ich wüsste nicht welchen. Das ganze Design um ip_up_events herum ist "buggy 
as hell", denn ip_up_events=yes sagt überhaupt nichts darüber aus, welche 
Netze über den jeweiligen Circuit geroutet werden. Es könnte z.B. ein 
Dialup-Circuit in die Firma sein. Dann bringt es chronyd oder OpenVPN aber 
nichts, weil der chronyd seine NTP-Server im Internet darüber ohnehin nicht 
erreichen kann.

> Wie im letzten Beitrag geschildert, ist der Zeitpunkt insofern *nicht*
> unerheblich, weil der Inhalt der Variablen durch später folgende
> Skripte wieder geändert werden kann. Es hilft gar nichts, ip_up_events
> in rc320.route auf "no" zu setzen, wenn die Variable gleich danach in
> rc340.circuits.isdn wieder auf "yes" gesetzt wird. Dass das
> ip_up-Ereignis erst viel später (unter bestimmten Bedingungen)
> ausgelöst wird, hat damit nichts zu tun.

Das stimmt sicherlich. Doch warum sollte ip_up_events auf "no" gesetzt 
werden, außer am Anfang der Initialisierung? Schließlich weiß man zu diesem 
Zeitpunkt noch nicht, ob es Circuits geben wird.

> 
> Was war eigentlich der Grund, die Logik "default=yes, bei Bedarf auf no
> setzen" auf "default=no, bei Bedarf auf yes setzen" umzudrehen?

An fli4l 3.1.1 habe ich nicht mitentwickelt. Dennoch erscheint mir die 
jetzige Herangehensweise korrekter: Wenn es Circuits gibt, dann gibt es ip-
up-Ereignisse, wenn nicht, dann nicht. Warum ist das für dich verkehrt 
herum? Die Herangehensweise von fli4l 3.1.1 ist doch verkehrt, wenn keine 
Circuits und nur eine Nicht-Default-Route für ein lokales Netz wie 
10.0.0.0/24 konfiguriert wird, denn dann denken die fli4l-Pakete 
fälschlicherweise, dass es ip-up-Ereignisse gibt, was falsch wäre.

Wie oben schon gesagt liegt der grundlegende Fehler in der Vereinfachung: 
Die Existenz von _irgendwelchen_ Einwählvorgängen sagt _überhaupt nichts_ 
aus. Wichtig wäre zu wissen, ob man darüber die Hosts ansprechen kann, die 
man braucht (NTP-Server, OpenVPN-Peers etc.). Das kann aber eine simple 
Boole'sche Variable nicht leisten.

> 
> Ich kann mir nicht einmal mit dem opt_usercmd behelfen, weil
> rc990.usercmd erst nach rc990.base ausgeführt wird :(

Was ich machen kann ist, dass ein ip-up _immer_ bei einer statischen 
Default-Route erzeugt wird, unabhängig von ip_up_events. So wird es 
schließlich auch im FFL-506-Zweig gemacht. Damit könnte ich die 
ip_up_events-Geschichte endgültig entfernen, auch im trunk (im FFL-506-Zweig 
ist ip_up_events schon seit Monaten nicht mehr enthalten). Das Ganze ist 
aber etwas fragil, denn wenn jemand eine statische Default-Route _und_ einen 
Circuit mit Default-Route konfiguriert, dann geht's in die Hose. Wir könnten 
jetzt vermuten, dass das niemand macht, aber wer weiß...

> gibt es schon eine grobe Schätzung, wann der FFL-506-Zweig zum trunk
> "befördert" wird, d.h. eine vergleichbare Stabilität (auch
> hinsichtlich der Konfiguration) aufweisen wird?

Sagen wir's mal so: Ich arbeite daran fast jeden Tag, und ab Mitte Juni habe 
ich 3 1/2 Monate Freiquartal (frei von Lehre, nicht frei von Forschung). 
Vielleicht August / September? Ich hoffe es.


Gruß,
-- 
Christoph Schulz
[fli4l-Team]