[vz-users] Problem beim restore mit dbcopy

Tobias Lehr tobias.lehr at me.com
Tue Apr 2 18:27:00 CEST 2019 

Hallo,

Das habe ich auch grade gefunden, weil ich parallel im wiki gesucht habe, muss mir angewöhnen erst im wiki zu schauen, bevor dich euch mit lästigen Fragen nerve.

Die Cronjobs fehlen tatsächlich, werde das mal nachholen und dann sehen ob es ohne timeouts läuft.

Gruß Tobias
> Am 02.04.2019 um 18:22 schrieb Frank Richter <frank.richter83 at gmail.com>:
> 
> Möglicherweise fehlen im Image die Cronjobs noch. Siehe Wiki unter Datenmengen.
> 
> Kannst ja aggregate erstmal manuell laufen lassen und dann Cronjobs anlegen. day und hour reichen normalerweise, mit minute wird die aggregate-Tabelle auch groß...
> 
> Grüße
> Frank
> 
> Tobias Lehr <tobias.lehr at me.com <mailto:tobias.lehr at me.com>> schrieb am Di., 2. Apr. 2019, 18:14:
> Hallo,
> 
> Das ist das Ergebnis: {"version":"0.3","capabilities":{"database":{"data":{"rows":363139,"size":33079296},"aggregation":{"rows":0,"size":49152,"ratio":0}}}}
> 
> sieht tatsächlich so aus als ob in aggregation keine Werte stehen. Aber die wird bei einer Sicherung mit dbcopy auch nicht mitgesichert, und folglich auch nicht restored. Ich dachte die Aggregation erstellt sich dann selbst? Muss ich das irgendwo aktivieren? Ist wie gesagt das out of the box vom letzten image, war davon ausgegangen, das ich hier nichts mehr groß machen muss.
> 
> Sorry für die vielen, in euren Augen vielleicht dummen Fragen, aber ich bin halt ein ziemlicher Noob auf dem Thema, versuche aber zu lernen.
> 
> Gruß Tobias
>> Am 02.04.2019 um 17:34 schrieb Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>>:
>> 
>> Hallo Tobias,
>> 
>> hört sich an als würde die Aggregation nicht richtig laufen. Probier mal http://IP/api/capabilities/database.json <http://ip/api/capabilities/database.json>
>> 
>> Grüße
>> Frank
>> 
>> Tobias Lehr <tobias.lehr at me.com <mailto:tobias.lehr at me.com>> schrieb am Di., 2. Apr. 2019, 16:07:
>> Hallo Andreas,
>> 
>> ja, aber auf andere Art, da es sich nur um ein Testsystem gehandelt hat, habe ich kurzerhand einfach das aktuelle image vom 26.03. aufgespielt und habe dann die Daten importiert. Die letzte mail von dir, mit der Bemerkung das kein php7.1 installiert ist, ist bei mir leider im spam gelandet und ich habe davon nichts mitbekommen. Aber es war sogar php 7.3 installiert, sonst hätte ich ja gar kein update machen können, da ja mindestens php7.1 erforderlich ist und mein altes image ja noch mit php 7.0 lief.
>> 
>> Aber beim neuen image läuft ja ppm als weiserer, und hier habe ich das problem das er beim laden eines größeren Zeitraumes, Woche oder Monat oder Jahr einen Gateway timeout bringt. Liegt das an einer falschen Konfiguration, oder an der Hardware. Das Testsystem ist ein Raps 1 Model B+. 
>> 
>> Gruß Tobias
>> 
>>> Am 02.04.2019 um 09:05 schrieb Andreas Götz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>>:
>>> 
>>> Hi Thomas,
>>> 
>>> Problem gelöst?
>>> 
>>> Viele Grüße,
>>> Andreas
>>> 
>>> Am 31.03.2019 um 01:06 schrieb Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>>:
>>> 
>>>> Ich rate: Du hast kein php 7.1 installiert und im apache aktiviert.
>>>> 
>>>> Viele Grüße, Andreas 
>>>> 
>>>> Am 30.03.2019 um 22:08 schrieb Tobias Lehr <tobias.lehr at me.com <mailto:tobias.lehr at me.com>>:
>>>> 
>>>>> Hallo,
>>>>> 
>>>>> Also unter /var/log/apache2/error.log steht folgendes:
>>>>> 
>>>>> PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/apc.so' - /usr/lib/php/20151012/apc.so: undefined symbol: zif_apcu_store in Unknown on line 0
>>>>> [Sat Mar 30 22:05:47.294611 2019] [mpm_prefork:notice] [pid 7743] AH00163: Apache/2.4.25 (Raspbian) configured -- resuming normal operations
>>>>> [Sat Mar 30 22:05:47.295141 2019] [core:notice] [pid 7743] AH00094: Command line: '/usr/sbin/apache2'
>>>>> [Sat Mar 30 22:06:06.041997 2019] [:error] [pid 7749] [client 192.168.178.55:59060 <http://192.168.178.55:59060/>] PHP Parse error:  syntax error, unexpected '?' in /home/pi/volkszaehler.org/vendor/symfony/yaml/Parser.php <http://volkszaehler.org/vendor/symfony/yaml/Parser.php> on line 509, referer: http://192.168.178.128/ <http://192.168.178.128/>
>>>>> 
>>>>> ich habe die datei geleert und dann einen neuen Versuch gemacht. Wobei das Frontend geladen wird, nur eben mit dem Fenster NEtwork Error und da als Meldung Internal Server Error.
>>>>> 
>>>>> Gruß Tobias
>>>>>> Am 30.03.2019 um 21:59 schrieb Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>>:
>>>>>> 
>>>>>> Internal Server Error? Was steht im apache error log? Als Suchspiel macht dad keinen Spass ;)
>>>>>> 
>>>>>> Viele Grüße, Andreas 
>>>>>> 
>>>>>> Am 30.03.2019 um 21:08 schrieb Tobias Lehr <tobias.lehr at me.com <mailto:tobias.lehr at me.com>>:
>>>>>> 
>>>>>>> Hallo,
>>>>>>> 
>>>>>>> So ich habs jetzt nicht hinbekommen.
>>>>>>> 
>>>>>>> Was genau in der .htaccess drin stehen muss weiß ich leider nicht. Hier mal der inhalt davon:
>>>>>>> 
>>>>>>> # allow access
>>>>>>> <IfModule mod_authz_core.c>
>>>>>>>         Require all granted
>>>>>>> </IfModule>
>>>>>>> 
>>>>>>> # disable negotiation to avoid rewrite rule conflicts
>>>>>>> <IfModule mod_negotiation.c>
>>>>>>> #    Options -MultiViews
>>>>>>> </IfModule>
>>>>>>> 
>>>>>>> # enable this rule if using ppm middleware
>>>>>>> <IfModule mod_proxy.c>
>>>>>>>         # RewriteEngine On
>>>>>>>         # RewriteRule ^middleware(.php)?(/.*)? http://localhost:8080$2 <http://localhost:8080$2> [P]
>>>>>>>         # RewriteRule ^api(/.*)? http://localhost:8080$1 <http://localhost:8080$1> [P]
>>>>>>> </IfModule>
>>>>>>> 
>>>>>>> <IfModule mod_rewrite.c>
>>>>>>>         RewriteEngine On
>>>>>>>         RewriteRule ^middleware(/.*)? middleware.php$1 [L]
>>>>>>>         RewriteRule ^api(/.*)? middleware.php$1 [L]
>>>>>>> 
>>>>>>>         # frontend alias
>>>>>>>         RewriteRule ^frontend/(.*) $1 [L]
>>>>>>> </IfModule>
>>>>>>> 
>>>>>>> <IfModule mod_headers.c>
>>>>>>>     Header set Content-Security-Policy "default-src 'self'; connect-src * ws: wss: http: https:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
>>>>>>> </IfModule>
>>>>>>> 
>>>>>>> desweiteren habe ich nach der Anleitung im wiki middelware installieren -> Alternativ: Apache als Server, folgendes gemacht
>>>>>>> 
>>>>>>> sudo a2enmod rewrite -> Ergebnis Module rewrite already enabled
>>>>>>> 
>>>>>>> sudo nano /etc/apache2/apache2.conf 
>>>>>>> 
>>>>>>> Den block <Directory /var/www/>
>>>>>>>         Options Indexes FollowSymLinks
>>>>>>>         AllowOverride None
>>>>>>>         Require all granted
>>>>>>> </Directory>
>>>>>>> in 
>>>>>>> 
>>>>>>> <Directory /var/www/>
>>>>>>>         Options Indexes FollowSymLinks
>>>>>>>         AllowOverride All AuthConfig
>>>>>>>         Require all granted
>>>>>>> </Directory>
>>>>>>> geändert.
>>>>>>> 
>>>>>>> Das Ergebnis ist das jetzt kein Network Error Not Found kommt, sondern Network Error Internal Server Error.
>>>>>>> 
>>>>>>> Gruß Tobias
>>>>>>> 
>>>>>>>> Am 30.03.2019 um 11:09 schrieb Tobias.lehr at me.com <mailto:Tobias.lehr at me.com> <tobias.lehr at me.com <mailto:tobias.lehr at me.com>>:
>>>>>>>> 
>>>>>>>> Hallo Andreas, 
>>>>>>>> 
>>>>>>>> Danke für deine Hilfestellung. Das muss ich mir in ruhe anschauen. Ich habe in all den genannten Files nicht verändert. 
>>>>>>>> 
>>>>>>>> Das Problem mit den untracked files hab ich ja gelöst, bin mir aber nicht bewusst da was geändert zu haben. Aber wie gesagt das problem ist ja gelöst.
>>>>>>>> 
>>>>>>>> Gruß Tobias
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -------- Ursprüngliche Nachricht --------
>>>>>>>> Betreff: Re: [vz-users] Problem beim restore mit dbcopy
>>>>>>>> Von: Andreas Götz 
>>>>>>>> An: "volkszaehler.org <http://volkszaehler.org/> - users" 
>>>>>>>> Cc: 
>>>>>>>> 
>>>>>>>> Wie sieht htdocs/.htaccess aus? Ist modrewrite im Apache enabled und AllowOverride gesetzt? Irgendwo da liegt der Fehler weil einfach /api nicht gefunden wird. 
>>>>>>>> 
>>>>>>>> Die untracked files deuten darauf hin dass Du von Hand irgendwo rumeditiert hast. Da musst Du Dir selber helfen da nicht nachvollziehbar. 
>>>>>>>> 
>>>>>>>> Viele Grüße,
>>>>>>>> Andreas
>>>>>>>> 
>>>>>>>> Am 30.03.2019 um 09:24 schrieb Tobias Lehr <tobias.lehr at me.com <mailto:tobias.lehr at me.com>>:
>>>>>>>> 
>>>>>>>> Hallo Andreas,
>>>>>>>> 
>>>>>>>> Also dbcopy ist jetzt nach einigem hängen und würgen beim update Prozess in Ordnung. git und composer sagten ja zuerst das alles aktuell ist und dann hatte ich problem mit irgendwelchen Files die untracked waren, aber mit coogle hab ich das hinbekommen, das update ist durchgelaufen und dbcopy kopiert jetzt von sqlite zu mysql.
>>>>>>>> 
>>>>>>>> <Bildschirmfoto 2019-03-30 um 01.14.45.png>
>>>>>>>> 
>>>>>>>> ABER
>>>>>>>> 
>>>>>>>> irgendwie hat der ganze updatekram dem rest nicht gut getan. wenn ich das Frontend aufrufe bekomme ich folgende Meldung:
>>>>>>>> 
>>>>>>>> <Bildschirmfoto 2019-03-30 um 09.22.22.png>
>>>>>>>> <Bildschirmfoto 2019-03-30 um 09.22.33.png>
>>>>>>>> 
>>>>>>>> wenn ich die Meldung mit ok weg klicke  und auf Kanal hinzufüge klicke, dann kommt diese Meldung:
>>>>>>>> 
>>>>>>>> <Bildschirmfoto 2019-03-30 um 09.22.50.png>
>>>>>>>> 
>>>>>>>> <Bildschirmfoto 2019-03-30 um 09.22.56.png>
>>>>>>>> 
>>>>>>>> Ich vermute mal das das mit dem Update auf die Aktuelle Version zusammen hängt und irgendwie noch ne configuration falsch ist. Aber ich muss gestehen das ich gerade den Überblick verloren habe, welche config datei jetzt was genau konfiguriert, bzw. welche config datei obsolet ist, bzw. welche ab jetzt zu verwenden sind.
>>>>>>>> 
>>>>>>>> Ihar hattet für solche Fälle vor ein paar Tagen von einem Fragen Katalog gesprochen, ich finde ihn nur nicht mehr. 
>>>>>>>> 
>>>>>>>> das einzige an das ich mich jetzt noch erinnern kann, ist die PHP version:
>>>>>>>> 
>>>>>>>> PHP 7.3.3-1 (cli) (built: Mar  7 2019 19:43:34) ( NTS )
>>>>>>>> Copyright (c) 1997-2018 The PHP Group
>>>>>>>> Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies
>>>>>>>>     with Zend OPcache v7.3.3-1, Copyright (c) 1999-2018, by Zend Technologies
>>>>>>>> 
>>>>>>>> Gruß Tobias
>>>>>>> 
>>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20190402/4c59598c/attachment-0001.html>

More information about the volkszaehler-users mailing list