Synology-Forum.nl
Packages => 3rd party Packages => SickBeard => Topic gestart door: Woody197 op 26 juni 2015, 08:46:56
-
Beste mede forum leden,
Ik ben al een tijdje bezig om het sickbeard verhaal juist werkend te krijgen op me NAS heb al heel veel verschillende dingen geprobeerd maar helaas zonder enig resultaat. Is er iemand die mij daarmee kan helpen diverse handleidingen heb ik al geprobeerd maar kreeg telkens foutmeldingen met Python en als ik die niet kreeg dan was de fork niet goed etc etc.
Ik weet dat dit natuurlijk al vele malen is uitgekauwd maar als nog de vraag.
Misschien is er een andere optie te vervanging van het sickbeard verhaal dan hoor ik dat graag.
Mvg
Woody
-
Sickbeard wordt niet of nauwelijks meer onderhouden.
Je kunt beter SickRage gebruiken, dat is een fork die nog actief onderhouden wordt.
Zorg ervoor dat je de SynoCommunity als source in je packagecentre hebt staan (http://packages.synocommunity.com/).
Installeer SickRage.
Deze versie installeert automatisch de juiste Python versie en Git als dat nog niet op je Nas staat.
Je hoeft dus verder niets meer zelf in te stellen.
-
Beste Ben,
dank voor het antwoord alvast had sickrage ook geinstalleerd als ik er op klik dan gaat ie naar een webpagina die vervolgens dan niet reageert " ERR_CONNECTION_TIMED_OUT " zijn er dingen die nog ingesteld moeten worden of etc.
-
Nee zou niet nodig moeten zijn.
Heb vorige week zelf SickRage opnieuw op m'n test Nas geinstalleerd en werkt gewoon.
Heb je Sickrage wel gestart en draait hij ook (controleren in het package centre)
Heb je wel dit commando gebruikt?
http://<ipadres van je Nas>:8899
In plaats van ipadres kun je natuurlijk ook de naam van je Nas gebruiken.
Edit: Typo gecorrigeerd (8889 --> 8899) :oops:
-
Net ook even geïnstalleerd in test, recht toe recht aan, werkt gewoon.
[attachimg=1]
http://<ipadres van je Nas>:8889
Denk een typo, moet poort 8899 zijn ;)
Maar goed, als je op het icoontje klikt wordt het ook 8899 en /home/ wordt er ook auto achtergezet. ;D
-
Ik ga, denk ik, ook overstag 8)
Ziet er wel goed uit maar is vast even wennen.
-
Beste Ben,
Sickrage draait gewoon maar ik denk dat het komt omdat ik me bedrijfswebsite gebruik ipv ip adres.
-
Heb je de juiste poort doorgezet?
Ik kan er via mijn domeinnaam prima bij.
-
waar zat dat ook alweer toestemming aan die desbetreffende poort geven ?? hih een echte noob vraag maar zit effe niet thuis.
-
In je router?
Daar zet je de juiste poorten open richting je NAS
-
ach ja vermoeiende dag maar inderdaad lol je hebt gelijk de router ga dat wel doen als ik thuis ben mocht het niet lukken op de een of andere vage manier dan kom ik weer op dit draadje...
-
Zou het thuis eerst maar eens proberen en als dat werkt kun je altijd poort 8899 nog forwarden naar je NAS.
Zou daar wel even voorzichtig mee zijn, als je dat zomaar forward kan iedereen bij je SickRage komen en wat is het nut om er vanaf je werk bij te kunnen?
-
Je zet er uiteraard een userid en wachtwoord op 8)
Ik gebruik het al vrij lang van buiten af, kan je het allemaal een beetje in de gaten houden.
-
Over op Sickrage, werkt leuk.
Alleen jammer dat het niet overweg kan met LDAP gebruikers.
-
Ja ben ook erg tevreden over SickRage.
Ik gebruik zelf geen Ldap, maar kon SickBeard daar wel mee overweg dan?
-
Niet echt maar Sickbeard kon ik al ldap gebruiker wel benaderen en had toegang.
Nu met Sickrage krijg ik dat niet voor elkaar, geen toegang.
Ok, als admin wel dus ik kan er mee vooruit.
-
Er is nu een groep "sc-media" bijgekomen waarin de SickRage gebruiker zit.
Je kunt die groep dus meer rechten geven, zonder dat de groep "users" die ook meteen krijgen.
-
Vreemd, ik heb wel een sc-media group, maar er zitten geen gebruikers in...
Iemand enige suggestie?
ik heb gisteren de versie 20150526-1 geïnstalleerd. Maar dus zonder ene gebruiker in de groep sc-media.
-
Die groep wordt aangemaakt door een aantal packages van de Synocommunity.
Daar zitten de 'hidden' gebruikers in waaronder o.a. SickRage draait.
Hierdoor kunt je via de groeps rechten van sc-media rechten uitdelen zonder dat te moeten doen via de groep 'users' zoals dat voorheen moest.
Wat ze gedaan hebben is alle downloadpackages (NZBget, SABnzbd, pyLoad, Transmission, rTorrent, Deluge etc) in de groep sc-media stoppen.
-
Wat ze gedaan hebben is alle downloadpackages (NZBget, SABnzbd, pyLoad, Transmission, rTorrent, Deluge etc) in de groep sc-media sc-download stoppen.
^ftfy ;)
Zie de volgende link voor grofweg welke packages in welke groep zitten: https://github.com/SynoCommunity/spksrc/pull/1649#issue-68085785.
Op dit moment zijn Sickrage in sc-media, en nzbget(-testing) en pyload in sc-download actief. Voor alle andere packages in de lijst zijn die groepen nog niet actief, en kan alleen de 'users' groep gebruikt worden.
-
Bij NZBGet is de gebruiker niet hidden, daar zie ik in de groep sc-download als member nzbget.
Dus lijkt niet consistent te zijn doorgevoerd en roept dan bij mij vragen op....
-
Hoe kijk jij dan naar de members van die groep?
-
Hij is wel hidden, want je ziet die gebruiker niet in de lijst van gebruikers staan en je kunt die gebuiker ook niet zelf rechten geven.
Je kunt alleen in de groep sc-download gebruikers toevoegen of verwijderen en daar zie je de "hidden" gebruikers dan.
Alleen in de groep "users" kan dat weer niet omdat die groep een systeemgroep van DSM is en de DSM interface gemaakt is om dat daar niet toe te laten.
-
In de groep sc-download zie ik via edit member als enige member staan: nzbget.
In de groep sc-media zie ik via edit members geen enkele member staan. En daar zou ik dan sickrage verwachten.
Bij de gebruikers zie ik inderdaad zowel nzbget als sickrage niet staan.
-
Bij mij staat "sickrage" daar wel als member.
Misschien heb jij SickRage geinstalleerd voor deze wijziging door de SynocCommunity werd ingevoerd?
Hoewel dat eigenlijk niet zou kunnen, want dan zou je die groep helemaal niet hebben.
-
Nee heb ik afgelopen vrijdag geïnstalleerd. Installatie lijkt verder wel "goed" gegaan te zijn...
Beetje vreemd dat de gebruiker niet lijkt te zijn aangemaakt en toegevoegd.
En hoe nu verder...
-
Ik ben jullie even kwijt :?:
Even het hele verhaal: SynoCommunity maakt alle package users zodanig aan dat deze _niet_ terug te vinden zijn in de DSM interface. Dat doen we expres. Deze users zijn (onzichtbaar) lid van de 'users' groep.
Recent is er een extra groep bijgekomen voor de packages sickrage en nzbget, om zo het beheren van rechten eenvoudiger te maken: de groepen sc-media en sc-download resp. Deze groepen zijn zichtbaar in DSM, maar, zoals gezegd, de members niet.
Tenzij je handmatig eea hebt gewijzigd, zou ik dus verwachten dat je geen enkele user in die groep ziet staan. Dat klopt ook met mijn ervaringen: ik heb net beide packages op een schone machine geinstalleerd, en inderdaad zijn de groepen wel zichtbaar, maar de users niet.
-
Alles duidelijk hoor.
Maar als je bij de groepen bijvoorbeeld sc-media selecteert en dan op "Edit Member" klikt kun je daar de members van die groep zien en eventueel members verwijderen en toevoegen.
Satch_23 zegt dat hij daar in de groep "sc-media" geen gebruiker "sickrage" ziet, terwijlk die er bij mij wel te zien is.
Dat "Edit Member" is niet mogelijk voor de groep "users", dat is door DSM "greyed out".
-
DrBean,
dank voor je reactie. Sickrage is een clean install geweest. Met andere woorden, was nog niet op mijn machine geïnstalleerd. Daar is zoals aangegeven een groep sc-media bij aangemaakt. Daarin zie ik via edit members géén users.
NZBGet heb ik eerder deze ge-update naar de meest recente versie. Daarbij is de groep sc-download aangemaakt en daarbij zie ik via edit members wel een user staan: nzbget.
Het verschil in installatie tussen beide pakketten is dus dat bij eentje het een eerste installatie betrof (Sickrage) en bij de andere een update (Nzbget). Mogelijk dat daar iets anders is gebeurd bij het aanmaken van de groepen en gebruikers.
edit/toevoeging:
@DrBean: kun je aangeven wat het juiste gedrag is wat wij kunnen en moeten verwachten?
Zoals e.g.:
- Alleen groepen die zichtbaar zijn (en via edit members kunnen/mogen we geen gebruikers zien)
of
- Groepen die zichtbaar zijn en via edit members kunnen/moeten we een gebruiker zien zoals e.g. nzbget in de groep sc-download.
-
Het proces waarmee we users aanmaken zorgt ervoor dat ze als 'systemuser' opgevoerd worden. DSM laat die users simpelweg niet zien. Dus ofwel 'onze' users zijn geen systemuser op jouw systeem, ofwel DSM doet rare dingen ;)
Maw, zelfs via 'Edit member' zou je die users niet moeten kunnen zien.
Voor Ben(V): heb jij misschien ooit de de user 'sickrage' handmatig aangemaakt, of misschien heb je bv '/etc/passwd' of 'etc/groups' gewijzigd?
En voor Satch_23: heb jij misschien ooit de user 'nzbget' handmatig aangemaakt of iets gewijzigd in bovengenoemde bestanden?
/edit: voor alle duidelijkheid, ik geef hierboven een idee of twee waarom die users toch zichtbaar zijn, mogelijk zijn er nog andere redenen te bedenken. Maar het maakt uiteindelijk weinig uit.
De voornaamste reden waarom we die package users onzichtbaar willen hebben heeft te maken met de zekerheid dat mensen niet per ongeluk de packages stukmaken door dingen te wijzigen aan die users.
-
DrBean,
zover ik mij kan herinneren heb ik nooit een gebruiker nzbget aangemaakt. Als dat al zo zijn geweest, dan is dat moet dat héél lang geleden zijn geweest (en heb ik die dus ooit ook weer verwijderd). Alleen kan ik mij niet bedenken waarvoor ik dat gedaan zou hebben.
[nog even voor de duidelijkheid: de gebruiker nzbget zie ik dus niet in de lijst met gebruikers staan.]
Wat ik met zekerheid kan stellen is dat ik geen van de door jou genoemde bestanden heb gewijzigd.
Mocht het zo zijn dat als het ooit aangemaakt (en wellicht ook weer verwijderd) hebben van een gebruiker problemen oplevert/kan opleveren dan is het wellicht handig om voor de gebruikersnaam als prefix ook 'sc-' te plaatsen. Kans dat een willekeurig iemand dat kiest als gebruiker is denk ik erg klein/nihil.
/edit:
inderdaad goed om de gebruikers onzichtbaar te houden. Alleen vroeg ik mij dus af waarom bij de een wel en de andere niet in de groep zichtbaar via edit members. /vage zinsconstructie veranderd :-)
Als het ooit aangemaakt (en eventueel inmiddels al verwijderd) hebben van een gebruiker problemen op kan leveren is dat denk ik wel een mogelijk issue-tje. En is de prefix sc- wellicht een optie. [probeer beetje mee te denken/helpen]
-
@DrBean
Nee ik heb nooit zo'n user aangemaakt en hij is ook gewoon hidden bij de users en je kunt er ook geen rechten aan toekennen.
Als je echter naar het "Control Panel" gaat, daar onder het kopje "File Sharing", "group" aanklikt krijg je een overzicht van de groepen.
Als je dan bijvoorbeeld "sc-media" selecteert dan kun je vervolgens op "Edit Members" klikken om de member van die groep te zien.
Bij mij zie ik dan sickrage staan.
Je kunt daar member verwijderen en toevoegen.
In de groep "sc-sincthing" zie ik daar een member "syncthing" staan.
Wat mij betreft allemaal prima hoor.
-
@Ben: ik heb het zelf niet geprobeerd - ik wil mij geen rare problemen op de hals halen en ik heb helaas niet de beschikking over een OTAP omgeving :P - , maar kun je dan ook de gebruiker sickrage uit de groep sc-media verwijderen? Als dat zo is is dat conform DrBeans beschrijving nou juist wat ze willen voorkomen.
-
Ja dat kun je doen.
Op dit moment is dat nog geen ramp, want die gebruiker zitten nog in de groep users en kun je dus via die groep rechten uitdelen.
Maar in de toekomst zou dat verdwijnen en dan wordt het wel een probleem.
Dus ja ik denk dat DrBean dat bedoelt.
Overigens ben ik persoonlijk van mening dat als iemand dat doet het z'n eigen schuld is.
-
Eens wat betreft eigen schuld.
Overigens blijft mijn vraag @DrBean wat nu de gewenste situatie is (zie eerdere post in deze thread)
Nu lijken zich dus twee situaties voor te doen (groep met gebruiker zichtbaar of groep zonder gebruiker zichtbaar).
-
Sorry, dacht dat ik die vraag al beantwoord had ::) Even alle punten op een rijtje, waarbij ik dan jullie laatste berichten ook even meeneem:
De gewenste cq verwachte situatie is dat de package users niet zichtbaar zijn in de DSM interface. Dwz: niet in de lijst van normale users, en ook niet in de 'Edit Members' lijst. Maar, zoals ik al zei, daar ga ik niet moeilijk over doen, om een rits verschillende redenen:
- Ik kan het niet reproduceren, dus ik houd het vooralsnog op een lokaal verschil tov mijn machines (en in dit geval geef ik doodleuk de schuld aan DSM ;));
- De package user zelf kan niet gewijzigd worden, anders dan verwijdering uit de sc-groep;
- Het package an sich gaat niet kapot als de package user niet in de sc-groep staat. Uiteraard heeft het als gevolg dat de package user geen rechten meer heeft op de mappen waar de sc-groep aan gekoppeld is, maar als dat verholpen is, dan werkt de applicatie gewoon weer. Dat is overigens ook het enige doel van die sc-groepen, de 'permissions granularity' verbeteren om het maar eens sjiek te zeggen;
- De package user kan niet uit de 'users' groep verwijderd worden via de DSM interface. Overigens zal deze koppeling wsl niet verdwijnen, o.m. vanwege backwards-compatibility;
- Het is nog niet officieel, maar we hebben begrepen dat Synology met DSM6 'echte' applicatieusers zal introduceren. Als eea bruikbaar is geïmplementeerd, dan gaan we dat inzetten.
De insteek van die users is dan dat ze wel zichtbaar zijn in DSM, maar niet te wijzigen, anders dan om rechten op shared folders/mappen te kunnen zetten of lid te maken van groepen. Als dat laatste je bekend voorkomt, dan kan dat kloppen ;)
-
Thanks voor het uitgebreidde antwoord.
Vind het helemaal prima zo en die toevoeging van die sc-.... groepen is wat mij betreft echt een aanwinst.
Nu hoeft je niet meteen al je users rechten te geven om alleen maar een applicatie ergens te kunnen laten schrijven.
Dat het op verschillende systemen anders werkt snap ik ook niet.
Dit is de eerste keer dat ik verschillen ondekt in Dsm.
Of ligt het aan de Dsm versie, ik gebruik Dsm 5.2.
Zal nog eens testen op m'n andere Nas al zit die ook op Dsm 5.2
Edit: Ook op m'n DS409 Nas kun je die group member gewoon zien, toevoegen en verwijderen.
Overigens vind ik het eigenlijk beter zo, maar dat is een persoonlijke smaak.
Zie hieronder:
-
Ook even getest maar hier geen leden (sickrage) in sc-media groep:
[attachimg=1]
[attachimg=2]
[attachimg=3]
-
Zou er verschil kunnen zitten tussen een installatie op een geupgrade DSM en "schone" DSM?
-
Als je upgrade krijg je helemaal die sc-media groep niet.
Upgrades worden binnen Sickrage zelf geregeld.
-
MMD bedoelde natuurlijk een schone installatie van een bepaalde DSM versie vs een geupgradede DSM.
Hier data van drie van mijn devices:
DSM5.0 (upgrade van 4.3, arm): geen users zichtbaar
DSM5.1 (schoon, x86): Ik kom er net achter dat daarop de users wel zichtbaar zijn in de groepen via 'Edit members'. Maar ik kan de package users alleen uit de groep verwijderen. Ik kan deze vervolgens niet zien als zijnde beschikbaar, dus ook niet toevoegen. Ik zie niet in dat we iets met die info opschieten overigens, dus fwiw: als iemand dit wil testen, doe dat niet op een productiemachine als je die groep gebruikt)
DSM5.2 (schoon, x86): geen users zichtbaar
Met de eerste twee apparaten is erg veel getest in de loop van de tijd, dus mogelijk niet 100% representatief.
Ik kan daar zo snel geen verband zien icm de eerder gemelde resultaten. Het zaait eerder meer verwarring ;)
-
Daar kwam ik op omdat ik dacht dat er sinds 5.0 of 5.1 iets aan de rechten in DSM veranderd was.
Sorry dat ik de boel nog verwarrender maak... ;D
-
Synology heeft volgens mij met alle 5.x releases wijzigingen doorgevoerd aan rechten :lol: 5.0 was veruit de meest vervelende vanuit packaging perspectief, dat wel.
-
Het blijft een misterie.
Mijn test Nas een Ds409 is altijd geupgrade van een Dsm 3.xx geloof ik.
Mijn Ds414 heb ik laatst voorzen van een geheel nieuwe Dsm 5.2 versie.
Op beide systemen kan ik de user zien.
Dus schiet mij maar lek, zal morgen eens op linux nivesu kijken.
-
Op dat niveau zag ik geen verschil tussen 5.1 en 5.2.
Ik dacht even dat het zou kunnen komen als het UID boven een bepaald nummer kwam (gezien dat op m'n 5.1 apparaat zowat alle packages staan), maar dat lijkt het niet te zijn.
-
Ik heb zoals eerder aangegeven een mix :=)
Te weten:
Op mijn 1512+ is de DSM meerdere keren ge-upgrade (sinds 2012). Nu: DSM 5.1-5022 Update 4.
Wat betreft Sickrage heb vorige week ik een install gedaan (was dus tot vorige week niet geïnstalleerd). Na install zag ik de groep sc-media. In deze groep is GEEN user zichtbaar
Wat betreft NzbGet: heb ik in het verleden (pre sc-group tijdperk) geïnstalleerd. Enige tijd geleden een upgrade gedaan en toen zag ik dat de groep sc-download is toegevoegd. In deze groep IS de user nzbget zien.