Re: [vz-dev] vzlogger install.sh

[Daniel Lauckner]

Morgen,


am Dienstag, 4. April 2017 um 23:14 hast du geschrieben:
> Die vzlogger install.sh hat Fehler.

Ich konnte da jetzt nur einen entdecken. Sorry dafür.

> UND dieser File müsste dann mit
> 'systemctl enable vzlogger.service' auch aktiviert werden.

Steht eigentlich im Wiki.

Kommt es nur mir unpassend vor den Dienst auch noch gleich fürn bootup
zu aktivieren? Üblich ist es nach meiner Auffassung jedenfalls nicht.

> Und es wäre schön, wenn im Wiki die Vorgehensweise noch dokumentiert 
> wäre (leider wurde das raus gelöscht).

Das einzige was im Wiki nicht beschrieben ist: Kopiere Datei x
nach y. Viel mehr macht das Script ja auch nicht.

Ich lass mir noch ne hübsche Formulierung dafür einfallen, fürs Wiki
reicht mir jetzt leider die Zeit nimmer.


mfg Daniel

[vz-dev] [volkszaehler/vzlogger] 2e9aa6: systemd wrong filename

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/volkszaehler/vzlogger
  Commit: 2e9aa6af27731720847f4f1d35d5526de3c0b40f
  
https://github.com/volkszaehler/vzlogger/commit/2e9aa6af27731720847f4f1d35d5526de3c0b40f
  Author: Daniel Lauckner 
  Date:   2017-04-05 (Wed, 05 Apr 2017)

  Changed paths:
M install.sh

  Log Message:
  ---
  systemd wrong filename


  Commit: ddc24a5d5c8b82789162114e5d32b2748ebb04d0
  
https://github.com/volkszaehler/vzlogger/commit/ddc24a5d5c8b82789162114e5d32b2748ebb04d0
  Author: J-A-U 
  Date:   2017-04-05 (Wed, 05 Apr 2017)

  Changed paths:
M install.sh

  Log Message:
  ---
  Merge pull request #312 from J-A-U/master

systemd wrong filename


Compare: 
https://github.com/volkszaehler/vzlogger/compare/99f8edbcb46d...ddc24a5d5c8b

[vz-dev] vzlogger install.sh

[Udo1]

Die vzlogger install.sh hat Fehler.



if [ ! -e "$systemd_unit" ]; then
echo
echo "could not find $systemd_unit"
echo "it is recommended to configure a vzlogger systemd service"
echo

read -p "add the systemd unit file? [y/N]" -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]; then
echo
echo "installing systemd unit file"
sudo sed -e "s|/etc/vzlogger.conf|$vzlogger_conf|g" < 
./etc/vzlogger.service > $systemd_unit
fi
fi

if [ ! -e "$vzlogger_conf" ]; then
echo
echo "could not find global config file $vzlogger_conf"
echo "make sure to configure vzlogger before running (see 
etc/vzlogger.conf)"
fi

if [ -n "$(pidof vzlogger)" ]; then
echo
echo "vzlogger is already running"
echo "make sure to restart vzlogger"
fi
fi



 Das funktioniert nicht.

Es wird ein File vzlogger.system erzeugt. Es müsste aber ein File 
vzlogger.service erstellt werden. UND dieser File müsste dann mit 
'systemctl enable vzlogger.service' auch aktiviert werden.


Und es wäre schön, wenn im Wiki die Vorgehensweise noch dokumentiert 
wäre (leider wurde das raus gelöscht).


Gruß
Udo

Re: [vz-dev] Erreichbarkeit Wiki

[Frank Richter]

Am 4. April 2017 um 18:35 schrieb Justin Otherguy :

> …wenn ich mich kurz einmischen darf:
>
> > Am 04.04.2017 um 18:27 schrieb Andreas Goetz :
> >
> >
> >> On 4. Apr 2017, at 18:05, Frank Richter 
> wrote:
> >>
> >> +1 von mir für standardmäßige Deaktivierung von Demo in der options.js.
> Ich glaube der Fall, dass jemand Demo als MW nutzt, das Frontend aber
> selbst installiert, dürfte eher exotisch sein.
> >>
> >> Damit werden wir die vielen Frontends, die eine Verbindung aufbauen
> wollen, aber erstmal nicht los. Wie wäre es mit nochmaligem Test des
> Push-Servers ohne Apache-Proxy (stattdessen zusätzlicher Port) oder mit
> abweichend konfiguriertem Proxy, so dass nur das Frontend von Demo
> Verbindungen aufbauen kann?
> >
> > Ich bleibe bei meinem Vorschlag: erst Analyse, dann demo umbauen. Wie
> sollen wir denn sonst was über das Verhalten vom Pushserver lernen?
>
> ich erkenne da keinen Widerspruch.
>

ich auch nicht - der Vorschlag ist ja nicht als Dauerlösung gedacht,
sondern zur Analyse: was passiert, wenn man die zig Frontends, die sich
(höchstwahrscheinlich unnötig) zum Demo-Pushserver connecten, mal abklemmt?


> Wir sollten im aktuellen Zustand das Verhalten analysieren und ggf. den
> Fehler beheben.
> Sobald das der Fall ist, können wir den Push-Server standardmäßig
> deaktivieren.
>
> Einverstanden?
>
>
> > Den PR könnt ihr ja unabhängig davon schonmal stellen…
>
> genau.
>
>
> Gruß, J.
>
>

Re: [vz-dev] Erreichbarkeit Wiki

[Justin Otherguy]

…wenn ich mich kurz einmischen darf:

> Am 04.04.2017 um 18:27 schrieb Andreas Goetz :
> 
> 
>> On 4. Apr 2017, at 18:05, Frank Richter  wrote:
>> 
>> +1 von mir für standardmäßige Deaktivierung von Demo in der options.js. Ich 
>> glaube der Fall, dass jemand Demo als MW nutzt, das Frontend aber selbst 
>> installiert, dürfte eher exotisch sein.
>> 
>> Damit werden wir die vielen Frontends, die eine Verbindung aufbauen wollen, 
>> aber erstmal nicht los. Wie wäre es mit nochmaligem Test des Push-Servers 
>> ohne Apache-Proxy (stattdessen zusätzlicher Port) oder mit abweichend 
>> konfiguriertem Proxy, so dass nur das Frontend von Demo Verbindungen 
>> aufbauen kann?
> 
> Ich bleibe bei meinem Vorschlag: erst Analyse, dann demo umbauen. Wie sollen 
> wir denn sonst was über das Verhalten vom Pushserver lernen?

ich erkenne da keinen Widerspruch.

Wir sollten im aktuellen Zustand das Verhalten analysieren und ggf. den Fehler 
beheben.
Sobald das der Fall ist, können wir den Push-Server standardmäßig deaktivieren. 

Einverstanden?


> Den PR könnt ihr ja unabhängig davon schonmal stellen…

genau.


Gruß, J.

Re: [vz-dev] Erreichbarkeit Wiki

[Andreas Goetz]

> On 4. Apr 2017, at 18:05, Frank Richter  wrote:
> 
> +1 von mir für standardmäßige Deaktivierung von Demo in der options.js. Ich 
> glaube der Fall, dass jemand Demo als MW nutzt, das Frontend aber selbst 
> installiert, dürfte eher exotisch sein.
> 
> Damit werden wir die vielen Frontends, die eine Verbindung aufbauen wollen, 
> aber erstmal nicht los. Wie wäre es mit nochmaligem Test des Push-Servers 
> ohne Apache-Proxy (stattdessen zusätzlicher Port) oder mit abweichend 
> konfiguriertem Proxy, so dass nur das Frontend von Demo Verbindungen aufbauen 
> kann?

Ich bleibe bei meinem Vorschlag: erst Analyse, dann demo umbauen. Wie sollen 
wir denn sonst was über das Verhalten vom Pushserver lernen?

Den PR könnt ihr ja unabhängig davon schonmal stellen…

> 
> Grüße
> Frank

Viele Grüße, Andreas

> 
> Am 4. April 2017 um 17:27 schrieb Andreas Goetz  >:
> 
> > On 4. Apr 2017, at 17:00, Jakob Hirsch  > > wrote:
> >
> > Am 04.04.2017  um 14:47 schrieb Justin Otherguy:
> >> inzwischen ist klar: es lag am zusätzlich aktivierten Push-Server.
> >> Andreas schaut sich nochmal an, ob es am Push-Server an sich liegt
> >> oder die Beliebtheit desselben die Maschine überfordert :-)
> >
> > Vielleicht muß der Push-Server selbst nicht mal so beliebt sein. Immerhin 
> > connected jedes VZ-Frontend mit Default-Config zum Demo-Push-Server, keine 
> > Ahnung, wie gut React(?) mit ein paar Dutzend (Hundert?) connections 
> > umgehen kann. Wenn du das im Log hast, wäre ja mal interessant, die 
> > VZ-Nutzung zu ermitteln. Ansonsten finde ich das ganze unter 
> > privacy-Gesichtspunkten nicht soo optimal...
> 
> Ihr könnt das gerne ändern. Historisch hatten wir eine Installation die OOTB 
> bereits Kanäle abonnieren konnte. Ich hänge da nicht dran…
> 
> Viele Grüße,
> Andreas
> 
> 

Re: [vz-dev] Erreichbarkeit Wiki

[Frank Richter]

+1 von mir für standardmäßige Deaktivierung von Demo in der options.js. Ich
glaube der Fall, dass jemand Demo als MW nutzt, das Frontend aber selbst
installiert, dürfte eher exotisch sein.

Damit werden wir die vielen Frontends, die eine Verbindung aufbauen wollen,
aber erstmal nicht los. Wie wäre es mit nochmaligem Test des Push-Servers
ohne Apache-Proxy (stattdessen zusätzlicher Port) oder mit abweichend
konfiguriertem Proxy, so dass nur das Frontend von Demo Verbindungen
aufbauen kann?

Grüße
Frank

Am 4. April 2017 um 17:27 schrieb Andreas Goetz :

>
> > On 4. Apr 2017, at 17:00, Jakob Hirsch  wrote:
> >
> > Am 04.04.2017 um 14:47 schrieb Justin Otherguy:
> >> inzwischen ist klar: es lag am zusätzlich aktivierten Push-Server.
> >> Andreas schaut sich nochmal an, ob es am Push-Server an sich liegt
> >> oder die Beliebtheit desselben die Maschine überfordert :-)
> >
> > Vielleicht muß der Push-Server selbst nicht mal so beliebt sein.
> Immerhin connected jedes VZ-Frontend mit Default-Config zum
> Demo-Push-Server, keine Ahnung, wie gut React(?) mit ein paar Dutzend
> (Hundert?) connections umgehen kann. Wenn du das im Log hast, wäre ja mal
> interessant, die VZ-Nutzung zu ermitteln. Ansonsten finde ich das ganze
> unter privacy-Gesichtspunkten nicht soo optimal...
>
> Ihr könnt das gerne ändern. Historisch hatten wir eine Installation die
> OOTB bereits Kanäle abonnieren konnte. Ich hänge da nicht dran…
>
> Viele Grüße,
> Andreas
>
>

Re: [vz-dev] Erreichbarkeit Wiki

[Andreas Goetz]

> On 4. Apr 2017, at 17:00, Jakob Hirsch  wrote:
> 
> Am 04.04.2017 um 14:47 schrieb Justin Otherguy:
>> inzwischen ist klar: es lag am zusätzlich aktivierten Push-Server.
>> Andreas schaut sich nochmal an, ob es am Push-Server an sich liegt
>> oder die Beliebtheit desselben die Maschine überfordert :-)
> 
> Vielleicht muß der Push-Server selbst nicht mal so beliebt sein. Immerhin 
> connected jedes VZ-Frontend mit Default-Config zum Demo-Push-Server, keine 
> Ahnung, wie gut React(?) mit ein paar Dutzend (Hundert?) connections umgehen 
> kann. Wenn du das im Log hast, wäre ja mal interessant, die VZ-Nutzung zu 
> ermitteln. Ansonsten finde ich das ganze unter privacy-Gesichtspunkten nicht 
> soo optimal...

Ihr könnt das gerne ändern. Historisch hatten wir eine Installation die OOTB 
bereits Kanäle abonnieren konnte. Ich hänge da nicht dran…

Viele Grüße, 
Andreas

Re: [vz-dev] Erreichbarkeit Wiki

[Frank Richter]

Am 4. April 2017 um 15:29 schrieb Andreas Goetz :

> Glaskugel -> Logging -> Auswerten...
>

Ich wollte ja in erster Linie wissen, ob es Erkenntnisse zur Nutzung gibt -
der Rest ist Theorie, schon klar.

Gerade noch gesehen: im Demo-Frontend sind offensichtlich 2 Middlewares
konfiguriert, Lokal und Demo, was in dem Fall ja identisch ist. Bei aktivem
Push-Server dürfte das Frontend dann statt einer zwei Verbindungen
aufbauen. Kann das ein Problem sein?
Zusätzlich bauen dann auch alle lokal installierten Frontends Verbindungen
zu Demo auf, weil via GitHub oder Image ein Frontend mit aktivierter
Demo-Middleware verteilt wird. Da kommen vermutlich einige Verbindungen
zusammen.

Grüße
Frank


> 2017-04-04 15:07 GMT+02:00 Frank Richter :
>
>> Hallo Justin, hallo Andreas,
>>
>> könnt ihr überblicken wie viele Kanäle auf demo tatsächlich mit
>> Push-Daten versorgt werden?
>> Denn wenn bis vor kurzem dort gar kein Push-Server lief, dürften ja nicht
>> allzu viele Konfigurationen existieren, die davon Gebrauch machen. Außerdem
>> produziert vzlogger bei nicht erreichbarem Push-Server laufend
>> Fehlermeldungen im Logfile, soweit ich weiß auch bei verbosity: 0.
>>
>> Oder reicht es zur Erzeugung der Systemlast schon aus, dass die von
>> Nutzern geladenen Frontends automatisch Subscriptions für die angezeigten
>> Kanäle machen, auch wenn da effektiv gar keine Daten übertragen werden?
>> Dann hätte es mit Beliebtheit nix zu tun, weil es ohne den Einfluss des
>> Benutzers passiert.
>>
>> Viele Grüße
>> Frank
>>
>> Am 4. April 2017 um 14:47 schrieb Justin Otherguy <
>> jus...@justinotherguy.org>:
>>
>>> Hi Udo,
>>>
>>> > Am 03.04.2017 um 09:52 schrieb Udo1 :
>>> >
>>> > Am 02.04.2017 um 22:34 schrieb Justin Otherguy:
>>> >> Mal sehen…
>>> > Also bis jetzt ist die Erreichbarkeit sehr gut.
>>>
>>> inzwischen ist klar: es lag am zusätzlich aktivierten Push-Server.
>>> Andreas schaut sich nochmal an, ob es am Push-Server an sich liegt oder
>>> die Beliebtheit desselben die Maschine überfordert :-)
>>>
>>> Danke schon mal für die Rückmeldungen!
>>>
>>>
>>> > Braucht es dann überhaupt einen neuen Server?
>>>
>>> Jein - jetzt nicht mehr dringend; allerdings ist die vKiste schon 3
>>> Jahre alt und inzwischen bekommt man deutlich mehr RAM (3-4 GB statt 1 GB)
>>> und mehr Platte für’s selbe Geld. Der Umzug geht inzwischen per Snapshot
>>> und sollte daher nicht mehr besonders weh tun (keine Neuinstallation).
>>>
>>> Ich warte jetzt also ein passendes Angebot ab und buche dann mal was
>>> Neues. Ich hoffe auf ein Oster-Special :)
>>>
>>>
>>> Gruß, J.
>>>
>>>
>>
>