Krijg Spotweb niet werkende.

[bronstijn]

Tja, dat spotweb opzetten gaat ook al niet zo soepel hier.

Geïnstalleerd volgens de methode en instellingen van @Birdy.
nginx, apache 2.2/2.4, maakt allemaal geen klap uit, blijf 'Undefined class constant 'MYSQL_ATTR_FOUND_ROWS' error krijgen... ook met de handmatige eerste retrieve.
Oplossing die zou moeten werken:

Code: [Selecteer]

De volgende handeling heeft mijn probleem opgelost:
-Login met putty als Root
-Ga naar de spotnet directory
-commando "php migrate-cache.php"
-dan pas het commando "php upgrade-db.php"werkt dus niet. Ook niet met de php56 aangeroepen versie.
Ik krijg dezelfde foutmelding.

Zal (ook) wel met versies van webstation etc voor ds418 te maken hebben.
Kan morgen nog eens op mijn 'oude' beestje (DS209-DS212j) een install proberen.

Wat is het toch mooi als het allemaal werkt, he...

[Birdy]

Heb je bericht gesplitst van hier en verplaatst naar deze rubriek.

[bronstijn]

Miste hem al... gaat ook van hot naar her
Heeft wel allemaal met elkaar te maken, maar toch ook weer niet.

[bronstijn]

Manmanman,
na omzwervingen (php settings grijs, niet aan te passen) spotweb kunnen installeren.
Maar nu hangt hij bij de install.php
Met phpMyAdmin kunnen zien dat de database wordt aangemaakt, maar er komen geen tabellen....
Iemand een volgende stap?

Eigen volgende stap:
spotweb verwijderd en opnieuw geinstalleerd (handmatig de  'Spotweb_noarch-all_20170305-1.spk' en daarna zonder opstarten bijgewerkt naar 20171126-1... No Joy.
PHP default profile bijgewerkt met openssl extensie, met phpinfo even gekeken (zou dat iets getriggerd hebben?)
En install.php doet wat.... next!

In 'database settings' scherm database user 'spotweb' het juiste ww meegegeven en 'verify database' geklikt (nog geen tabellen in database).
Vul usenetserver gegevens in - 'verify usenet server' (nog geen tabellen in database).
Heb 'spotweb type' als 'Public' gezet en de 'Administrative user' gegevens ingevuld - 'Create system' (logischerwijs worden de tabellen nu aangemaakt).
dbsettings.inc.php hoef ik niet aan te maken, staat er al met de juiste gegevens.
'Visit your Spotweb'
Ingelogd als administrative user en retentie op 365 gezet (voorlopig even goed zat).
Gelijk 'Remove everything' gekozen en "Retrieve spots after' op 1 november 2016 gezet (kijkt hij gelijk niet verder terug dan die datum) en 'Change' geklikt.
In putty '/usr/local/bin/php56 /volume2/web/spotweb/retrieve.php' uitgevoerd en hij begon te mopperen over ssl

Code: [Selecteer]

Warning: stream_socket_client(): unable to connect to ssl://news.sunnyusenet.com
:563 (Unable to find the socket transport "ssl" - did you forget to enable it wh
en you configured PHP?) in /volume2/web/spotweb/vendor/spotweb/nntp/src/Protocol
/Client.php on line 725
SpotWeb v0.68.29.32 on PHP v5.6.31 crashed

Fatal error occured while connecting to the newsserver:
  (-1) Error while connecting to server (server did not respond) [response: ""]
[response: ""]
In 'settings' in spotweb ssl uitgeschakeld en poort op 119 gezet, nu loopt de retrieve wel (lijkt het)

Code: [Selecteer]

root@XXXXXX:/volume2/web/spotweb# php56 retrieve.php --force
Removing Spot information which is beyond retention period,, done
WARNING: Using slow PHP based RSA, please enable the PHP OpenSSL extension whenever possible
Last retrieve at Thu Jan  1 01:00:00 1970
Retrieving new Spots from server news.sunnyusenet.com...
Appr. Message count:    1870231
First message number:   1235051
Last message number:    3105282
Current article number: 1235051

Retrieving 1235051 till 1240052
Lijkt alleen niet veel te gebeuren, heb begrepen dat dit lang kon duren...
php is iig druk bezig volgens de 'broncontrole'



Ik kijk over een uurtje wel eens een keer.

Uurtje later: idd, de retrieve loopt wel, maar met zo'n 5000 posts per dik uur (normaal zou dit een paar seconden mogen duren?)
NAS gereboot: retrieve nog eens gestart met 500 per vraag, geen volledige posts, geen volledige comments, modded posts verwijderen....  bijna 200 seconden per 500 stuks.
Is dit 'normaal' en moet ik nu wachten tot na de kerst of kan ik hier iets mee?



(We komen er wel....)

[bartmans99]

eerste x retrieven duurt idd paar dagen en proces heeft soms de neiging (bij mij en mijn usenet provider) om af te breken. Ik trek er 2 a 3 dagen voor uit. Maar zo lang je geen foutmelding krijgt en iedere keer nieuwe spots van recentere datum ziet, gaat alles goed.

[bronstijn]

Vooruit, we geven het wat tijd, maar als ik morgenochtend niks zie verschijnen in de lijst moet ik weer iets anders gaan proberen...
Heb nu apache 2.2 als webserver ingesteld
Ik had de rewrite van een .htaccess bestand nodig voor de api call uit sickrage, die werkt nu.
Nu dus nog iets om in te kunnen searchen

[mesa57]

Op een redelijke PC duurt een volledige retrieve ongeveer 4-6 uur. Maar de syno is helaas een factor x langzamer.
Het aantal spots wat je per slag(je) doet verminderen kan de snelheid idd positief beïnvloeden.

En heb je die warning gezien ? Geen openssl ---> inherent langzaam dus ! 

[bronstijn]

Ja, die warning zag ik ook al, openssl staat bij php5.6 wel aan, alleen gebruiken ze die niet voor het ophalen van.... enz.
Retentie ook al op 100 dagen gezet en vanaf 1 oktober binnenhalen... Toch vindt spotweb dat hij de hele bups langs moet.
Wazig.

Eerder vandaag:

Code: [Selecteer]

Appr. Message count:    1870231
First message number:   1235051
Last message number:    3105282
Current article number: 1235051
En zonet:

Code: [Selecteer]

Retrieving new Spots from server news.sunnyusenet.com...
Appr. Message count:    1869807
First message number:   1235610
Last message number:    3105417
Current article number: 1235610
Pfff, gaat nog ff duren ben ik bang. Met de huidige snelheid van 175s voor 500 spots een kleine 8 dagen?
Whatever, het is weekend!

[bronstijn]

Heb ondertussen door waarom ik op mijn DS418 de meldingen kreeg:
PHP Fatal error:  Uncaught Error: Undefined class constant 'MYSQL_ATTR_FOUND_ROWS' in /volume1/web/spotweb/lib/dbeng/dbeng_pdo_mysql.php:28

Hij lijkt in de cli versie de pdo driver niet te laden:
phpinfo van de 212j:

Code: [Selecteer]

PDO

PDO support => enabled
PDO drivers => mysql

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $
En die van de 418:

Code: [Selecteer]

PDO

PDO support => enabled
PDO drivers => 

Zo ziet dat deel op de Ds418 eruit als ik hem via webstation ophaal:


Dus dat gaat wel goed en verklaart meteen ook waarom het via de spotweb-interface wel lukt en met de handmatige retrieve niet.

Klein stapje verder dus.

Edit: klein stapje = groter stapje

Handmatig de php.ini aangevuld met

Code: [Selecteer]

extension = /volume1/@appstore/PHP5.6/usr/local/lib/php56/modules/pdo_mysql.so
extension = /volume1/@appstore/PHP5.6/usr/local/lib/php56/modules/openssl.so

Nu laadt hij ze wel, ik kan ook handmatig retrieven en hij is ook nog stukken sneller..... Als in een paar seconden per 5000 berichten.

Na een reboot van de NAS is de php.ini echter weer 'default' en kreeg ik de eerste keer de bekende melding:
PHP Fatal error:  Uncaught Error: Undefined class constant 'MYSQL_ATTR_FOUND_ROWS' in /volume1/web/spotweb/lib/dbeng/dbeng_pdo_mysql.php:28

opnieuw de 2 regels toegevoegd en hij is weer aan het verwerken (zelfs met ssl ingeschakeld op de nieuwsserver)

Komt allemaal goed, zo te zien.

@Birdy , misschien iets om te verwerken in de handleiding?

[mesa57]

pdo_mysql en openssl zijn gewoon php opties die je via webstation aan zou moeten kunnen zetten.
Als dat niet kan is het tijd voor een ticket naar Synology.

[bronstijn]

Extensies staan in de webstation interface ingesteld, worden ook op de webpagina's gebruikt, maar in de shell gebruikt hij blijkbaar een andere php.ini. worden andere  'Additional .ini files' gebruikt dan op de webpagina's...

'Additional .ini files parsed' volgens phpinfo.php webstation is/zijn '/usr/syno/etc/packages/WebStation/php_profile/f0fb273e-8083-4f5c-9188-7bb5a6311ed9/conf.d/user_settings.ini'
'Additional .ini files parsed' volgens diens 'phpinfo.php' is/zijn '/usr/local/etc/php56/conf.d/webstation-extensions.ini'

Vreemd dat ze daarvoor verschillende gebruiken, vooral omdat de namen op zich impliceren dat ze hetzelfde bedoelen.
Lijkt alsof ze de 'profielen' uit de beta van webstation nog niet in de shell hebben doorgevoerd.

Zal eens uitzoeken hoe dat gaat (een ticket naar Synology).

[mesa57]

Als je het PHP56 of PHP70 commando als cli gebruikt, worden ook de webstation instellingen gebruikt, in tegenstelling tot het PHP cli commando die zijn eigen php.ini heeft (tik maar eens php --ini of php 56 --ini in).

[bronstijn]

Eh, bij mij (DS418) worden voor de web- en cli versie van php56 verschillende ini's gebruikt.

De settings die ik in mijn vorige post liet zien zijn namelijk van php56 cli en web

phpinfo - web:


phpinfo - cli:


Inherent zijn dus de instellingen voor het handmatig retrieven van posts standaard niet correct (geen modules geladen, daarom de foutmeldingen)

Ik heb nu mijn 'aanpassingen' in de ........ teruggedraaid en de modules aan de '/usr/local/etc/php56/conf.d/webstation-extensions.ini' toegevoegd. Zo blijft hun flow intact en weet ik waar straks de wijzigingen eventueel moeten worden gemaakt.

[mesa57]

Welke dsm versie is dat ?

[bronstijn]

DSM 6.1.4-15217 Update 2

Webstation - 2.1.1-0129 (beta)
PHP 5.6 - 5.6.31-0053