Synology-Forum.nl
Packages => 3rd party Packages => CouchPotato => Topic gestart door: Jonazzty op 02 november 2014, 13:42:53
-
Hi,
Ik dacht vandaag om Couchpotato & Sickbeard rap even te installeren, maar helaas..
Bij couchpotato ben ik zodanig snel door de setup geklikt (im sorry..) dat ik niet eens weet/gezien heb wat de login gegevens zijn ervan. ik dacht "geen erg, effe herinstalleren" .. maar, je raad het al, dat lukt niet.
ALs ik in de package center opnieuw op "installeren" klik krijg ik de melding dat poort 5050 al gebruikt wordt en dat eerst moet verholpen worden of ik anders de appontwikkelaar moet contacteren.
lol?
kan iemand mij hiermee helpen en mij vertellen hoe ik ofwel couchpotato volledig kan verwijderen en opnieuw beginnen of hoe ik dit oplos?
Thanks.
-
Bestand /usr/local/etc/services.d/CouchPotato.sc of zoiets dergelijks (v.w.b. de naam) verwijderen met WinSCP.
Dan herinstalleren.
WinSCP:
1 - Zorg ervoor dat SSH-Service aan staat: Configuratiescherm > Terminal.
2 - Download: http://winscp.net/eng/download.php
3 - Installeer WinSCP
4 - Start WinSCP klik op nieuw
5 - Bestandsprotocol: SCP
6 - Adres doelcomputer: <NAS-IP>
7 - Poortnummer: 22
8 - Gebruikersnaam: root
9 - Opslaan
10 - Inloggen (Password van je admin)
-
en hoe geraak ik in die directory? via ftp dan? of?
-
Browsen in WinSCP (GUI).
-
ik heb een mac dus WinSCP lukt hier niet .. ik probeerde net via Cyberduck maar ik geraak niet verder dan dezelfde mappen die ik zie als ik via browser inlog en daar in de "finder" ga kijken... :-/
-
Om met SCP te kunnen werken heb je of OSX_SCP nodig (zie de Torrentboer op de hoek) of (betaalde versie van) Browser.
Uiteraard kun je ook m.b.v. SSH in e Terminal aan de slag gaan.
Bezet meldingen van poorten kun je ook oplossen door de NAS ter herstarten.
-
EN, zoals eerder aangegeven, let op punt 1, 8 en 10.
-
Of via de formele weg, een terminal openen (putty)
Inloggen als root met je admin password en dan het volgende commando geven:
/usr/syno/bin/servicetool --remove-configure-file --CouchPotato.sc
-
Om met SCP te kunnen werken heb je of OSX_SCP nodig (zie de Torrentboer op de hoek) of (betaalde versie van) Browser.
Uiteraard kun je ook m.b.v. SSH in e Terminal aan de slag gaan.
Bezet meldingen van poorten kun je ook oplossen door de NAS ter herstarten.
de nas ondertussen al 2x herstart maar deze melding blijf ik krijgen :
[attach=1]
als ik via terminal wil gaan dan lukt het precie ook niet ...
(https://www.synology-forum.nl/proxy.php?request=http%3A%2F%2Ff.cl.ly%2Fitems%2F2p3p421X280C353n2m1l%2FSchermafbeelding%25202014-11-02%2520om%252020.55.05.png&hash=89bec8f86f791190976a80cd7303ed33c2e959f2)
OSX_SCP kan ik ook niet vinden bij de vrienden van bitsnoop :(
-
Geeft eens het commando
ls /usr/local/etc/services.d
Om de exacte naam van dat .sc bestandje te zien.
-
het noemt hier idd blijkbaar couchpotatoserver.sc maar als ik dan
/usr/syno/bin/servicetool --remove-configure-file --couchpotatoserver.sc
ingeef krijg ik terug de "usage" te zien... :-/
-
Hmmm zal iets met het mountpoint te maken hebben.
Misschien eens in dezelfde directory gaan staan als waar dat .sc bestandje staat.
Als het daarna nog niet gaat kun je ook het bestandje deleten.
-
als ik het dan probeer krijg ik "Permission Denied" :(
-
Zucht.
Gewoon deleten dan maar.
Hij wordt toch weer aangemaakt bij de installatie.
-
domme vraag alweer, maar hoe dan? want als ik help ofzo typ voor de commands dan staat daar geen delete of iets dat er op trekt tussen :-/ ..
Built-in commands:
------------------
. : [ [[ alias break cd chdir continue eval exec exit export
false getopts hash help let local printf pwd read readonly return
set shift source test times trap true type ulimit umask unalias
unset wait
-
Het is rm
-
@Ben(V)
In den beginne had ik ook gezegd deleten dus, nu ben ik toch benieuwd wat:
/usr/syno/bin/servicetool --remove-configure-file <file>.sc
meer doet dan deleten, of is dat toch hetzelfde. ::)
-
Hij wordt dan ook uit de registratie van DSM gehaalt.
Is volgens het voorschrift van het synology package handbook.
Wordt gebruikt voor de firewall instellingen
Maar aangezien hij het package toch weer installeert zal het niet veel uitmaken.
Zal morgen of zo wel eens uitoeken waarom het bij hem niet ging.
-
Gokje.....
Met servicetool wordt de poort dan ook weer vrijgegeven ?
Dus, als je alleen delete, dan moet je ff rebooten anders blijft de poort bezet.
-
alright is gelukt :) nu nog leren werken met CP en Sickbeard en tis in orde,haha !
-
Mooi dat het gelukt is, dus met alleen deleten van de file lukte het om te herinstalleren ?
Maar dan begrijp ik het nut niet van "Hij wordt dan ook uit de registratie van DSM gehaalt."
-
ik begrijp er ook niets van.. mr heb dernet diezelfde command met "rm" gebruikt en dan terug ls om te zien.. het was er dan idd echt weg. dus dan even opnieuw geprobeerd en toen ik net zoals bij het begin opnieuw installeren :)
-
ik begrijp er ook niets van
Daar probeer ik nu dus achter te komen ;)
-
Als je een firewalll rule aanmaakt kun je daar kiezen uit welke packages met hun poort in de rule op wil nemen.
Als je alleen het bestandje verwijdert blijft hij daar staan terwijl het package weg is.
Eigenlijk moet het verwijderen van het package dit commando gebruiken, maar packages van voor DSM 5 doen dat niet.
Ik heb het ook niet bedacht hoor. Klachten naar Synology :lol:
-
Aaaaah, nu begrijp ik het.
Eigenlijk moet het verwijderen van het package dit commando gebruiken, maar packages van voor DSM 5 doen dat niet.
Dat geldt dan alleen voor Synology packages ?
Dus, 3e partij packages (zoals CouchPotato) gebruiken dat commando dus (nog) niet, neem aan dat TS op DSM 5 draait.
P.S., ik probeer het alleen te snappen 8)
-
Klopt maar de synocommunity is bezig de packages aan te passen.
Ik heb dit uitgezocht omdat ik daar met sickbeard en atosub tegen aan liep.
Die gebruiken dezelfde poort, maar kunnenzelf hun poort wijzigen
Helaas loop je dan ook tegen dat.sc bestandje aan.
Het autosub package is overigens door Matr1x aangepast en geeft bij een uninstall wel dit commando.
-
Duidelijk ! ;D
-
Voor alle duidelijkheid, het correcte commando is
/usr/bin/servicetool --remove-configure-file --package <<jouw_package>>.sc
Terzijde: Alle packages van Synology (die package-specifieke poorten gebruiken) alsmede die van SynoCommunity voeren bovenstaand commando uit tijdens deinstallatie, op elke DSM versie die de service configure file ondersteunt (DSM 4.0+)
Dat is nooit _niet_ het geval geweest. Ik begrijp niet waar het idee vandaan komt dat we, SynoCommunity, daar 'nog mee bezig zijn'? Ik ken maar een 'officieel' package waarbij het verwijderen van de service configure file over het hoofd is gezien: Zarafa.
-
Oeps slordig knip en plak werk --package weggevallen.
Sorry dat ik de verkeerde conclusie getrokken hem.
Ik heb op m‘n eigen Nassen gekeken en sommige packages waren wel voorzien en andere niet.
Dat komt ( achteraf gezien) natuurlijk doordat die al geinstalleerd waren voordat die aanpassingen gedaan zijn.
-
Np, ik probeer alleen onduidelijkheid te voorkomen :) Het gaat een eigen leven leiden, en veroorzaakt onnodige ruis.
SC-Packages die voor eind mei dit jaar zijn geïnstalleerd, en sindsdien niet meer geupdatet zijn, bevatten de code niet (maw: er wordt geen service configure file geplaatst, en dus ook niet verwijderd).
Voor die packages die het nodig hebben, zal het bij een update vanzelf toegevoegd worden: het zit al in de sourcecode.
Lang niet alle packages hebben die file nodig, daar zijn een paar criteria voor (draait als service, moet kunnen communiceren via tcp/udp, nvt voor packages die extern communiceren via andere services (httpd:80/443 etc)
-
Thx voor de info.
Toch vreemd dat bij de topic poster dan dit probleem ontstond met CouchPotato.
Als hij een oude versie had dan zou dat bestandje door het package niet geplaatst zijn en als hij een nieuwe versie had zou het bij het verwijderen verwijdert zijn.
-
Yes, dat is ook vreemd. Dat was dan ook de reden voor mijn reactie hier: https://github.com/SynoCommunity/spksrc/issues/1278#issuecomment-59610486
Ik heb rond de zomer een bug geopend bij Synology: de servicetool verwijderde de service configure file niet altijd. Dat zou Synology hebben gerepareerd bij de eerstvolgende minor update van DSM.
Helaas komt het nog steeds voor. Punt is, het komt bij een relatief klein aantal mensen voor, en er is er geen verband te ontdekken. Behoorlijk troubleshooten is onmogelijk door het gebrek aan reproduceerbaarheid: als het voorkomt, is dat maar eenmalig. Verwijder de file en probeer het een tweede keer: het werkt. En het blijft werken, ongeacht welke service configure files je daarna plaatst of verwijdert.
Een halve workaround is het toevoegen van rm-rf <service_configure_file> in de uninstaller. Imo is dat een waardeloze aanpak en ik zal zoiets ook niet toevoegen als ik het kan vermijden: er is een specifiek commando om precies te doen wat noodzakelijk is...alleen blijkbaar niet altijd. Ik zal waarschijnlijk een nieuwe bug openen, eerst wat tijd hebben om een inventarisatie van diverse ervaringen te doen.