OpenSSL + Sickrage en El Capitan

[Njay]

Hey tweakers,

vorige week voor een maat getracht sickrage te installeren op zijn mac mini met el capitan verse install
de guide gevolgt op http://www.htpcguides.com...ac-osx-usenet-torrent-tv/

alles gaat prima maar de openssl versie blijft steken op 0.98 diegene die volgens mij standaard bij osx zit.
ik krijg deze niet goed upgrade helaas

via brew geprobeerd en dan een brew link maar sickrage blijft melden dat we op 0.98 zitten ik moet deze hoger hebben anders werken de torrent downloads niet correct.

kan iemand helpen? hoe upgrade ik openssl naar een hoger lever dat ook de apps dit kunnen uitlezen en gebruiken

merci !

[z1rconium]

Sonarr wel eens geprobeerd ? (wist niet dat sickrage nog een ding was)

[CH4OS]

Wat vertelde Google toen je ging [google=upgrade openssl mac]?

How to upgrade OpenSSL in OS X?
Update OpenSSL on OS X with Homebrew

Zijn twee resultaten die ik vond.

[Njay]

z1rconium schreef op maandag 25 juli 2016 @ 10:08:
Sonarr wel eens geprobeerd ? (wist niet dat sickrage nog een ding was)

Nope en niet nodig sickrage werkt prima en wordt nog continue verbeterd

enig idee hoe het zit met openssl?

[Njay]

CH40S schreef op maandag 25 juli 2016 @ 10:14:
Wat vertelde Google toen je ging [google=upgrade openssl mac]?

How to upgrade OpenSSL in OS X?
Update OpenSSL on OS X with Homebrew

Zijn twee resultaten die ik vond.

Yep allemaal geprobeerd

downloaden en alles lijkt goed maar sickrage blijft de oude versie zien

[CH4OS]

Reboot ook geprobeerd na de upgrade? Kun je de output van

openssl version

eens geven, zodat je zeker weet of de upgrade al dan niet geslaagd is? Mocht dat ook de oude versie zijn, dan verwijst /usr/bin/openssl niet naar de nieuwe versie wellicht?

Als dat wel de nieuwe versie is, dan laadt Sick Rage denk ik de verkeerde in en kun je het pad binnen Sick Rage dan wellicht instellen? Is eventueel ook op te lossen met bovenstaande oplossing.

In de SickRage Wiki staan ook wat tips, die wellicht kunnen helpen.

[ Voor 213% gewijzigd door CH4OS op 25-07-2016 10:26 ]

[Njay]

CH40S schreef op maandag 25 juli 2016 @ 10:17:
Reboot ook geprobeerd na de upgrade? Kun je de output van

openssl version

eens geven, zodat je zeker weet of de upgrade al dan niet geslaagd is? Mocht dat ook de oude versie zijn, dan verwijst /usr/bin/openssl niet naar de nieuwe versie wellicht?

Als dat wel de nieuwe versie is, dan laadt Sick Rage denk ik de verkeerde in en kun je het pad binnen Sick Rage dan wellicht instellen? Is eventueel ook op te lossen met bovenstaande oplossing.

In de SickRage Wiki staan ook wat tips, die wellicht kunnen helpen.

Als ik inderdaad openssl version - a intik dan staat daar idd 0.98.
hoe kan ik in mac osx netjes de verwijzing linken naar de nieuwere versie die ik via brew heb binnen gehaald?

in sickrage valt niks in te stellen helaas ik denk de gegegevens van het systeem worden uitgelezen en getoond op de info pagina

[CH4OS]

Symlinken naar de juiste binary?

[Njay]

CH40S schreef op maandag 25 juli 2016 @ 10:34:
Symlinken naar de juiste binary?

Do tell me please !

ik ben een windows user op een mac mini haha ! dus weinig kennis ! maar wil me maat graag helpen

[CH4OS]

Het beste hernoem je /usr/bin/openssl eerst;

mv /usr/bin/openssl /usr/bin/openssl.old

zodat je altijd terug kan, dit zal je waarschijnlijk als root moeten doen, als dat zo is, dan sudo er voor zetten, ik denk dat die dan wel aanwezig is binnen OSX.

Vervolgens kan Google je wel vertellen hoe je een symlink maakt, het commando daarvoor is ln -s in elk geval.

[ Voor 23% gewijzigd door CH4OS op 25-07-2016 10:39 ]

[Njay]

Dit zou ik moeten doen dus?


brew update
brew install openssl
brew link --force openssl

openssl version -a

If one of the bad versions come up (1.0.1a-f), you can figure out which version of openssl you're using, this way:

which openssl

Often this is from /usr/bin. To make sure you get the updated version, drop a symlink into /usr/local/bin to point to the updated openssl, like this:

ln -s /usr/local/Cellar/openssl/1.0.1g/bin/openssl /usr/local/bin/openssl

[ Voor 3% gewijzigd door Njay op 25-07-2016 10:39 ]

[CH4OS]

Ah, op OSX zit het dus in /usr/local, mijn kennis van OSX gaat niet zo ver, hahaha! Maar principe komt op hetzelfde neer. Ik raad wel aan om (al is het voor de zekerheid) dan eerst

mv /usr/local/bin/openssl /usr/local/bin/openssl.old

te doen, dan kan je namelijk terug als het niet werkt! Wel het pad even checken of die klopt met

which openssl

zodat je weet waar het commando staat.

[ Voor 14% gewijzigd door CH4OS op 25-07-2016 10:48 ]

[Njay]

Super!

als je kijkt naar deze pagina:

http://www.htpcguides.com...ac-osx-usenet-torrent-tv/

en dan naar het stapje install open ssl met:

sudo pip install pyopenssl

zou ik dit dan moeten vervangen met de openssl vanuit brew , zodat hij niet pyopenssl installeert?

[CH4OS]

Nee, pyopenssl is de OpenSSL module voor Python.

[Njay]

CH40S schreef op maandag 25 juli 2016 @ 10:43:
Nee, pyopenssl is de OpenSSL module voor Python.

Ok dit koppelt python aan de openssl van macosx?

en daarna leg ik na de upgrade met brew een symlink zodat pyopenssl daarvan gebruik kan maken ?

thx voor je uitleg btw! mooi leer momentje zo

[CH4OS]

Dat zorgt dat Python dingen kan doen met OpenSSL idd. Ben wel benieuwd of het uiteindelijk werkt!

[ Voor 30% gewijzigd door CH4OS op 25-07-2016 10:47 ]

[Njay]

thanks ! ik ga vanavond of morgen aan de slag hiermee zo gauw er weer een versie osx draaid op zijn mac mini

nogmaals many thx ! en ik laat het zeker even weten

[Njay]

Helaas niks lijkt te werken, ik krijg openssl geupdate en alles ! Symlink lukt ook. Zelfs python zegt dat hij 1.0.1 draait maar sickrage blijft hoe dan ook de oude versie gebruiken 0.98 i am lost

En ik heb geen apt get op de terminal alleen brew
Dus ik kan de wiki niet volgen van sickrage met de ssl solutions

[ Voor 23% gewijzigd door Njay op 06-08-2016 10:55 ]

[Eitot]

Waarschijnlijk ligt het probleem in het feit dat root /usr/local/bin/openssl gewoon negeert. /usr/local/bin is een tertiaire locatie die pas na /usr/bin en /bin komt en aangezien OpenSSL 0.9.8 dus al in /usr/bin/openssl aanwezig is, zal /usr/local/bin/openssl nooit worden uitgevoerd. Als user zul je dat probleem niet hebben, omdat de installatie van Homebrew er al voor zorgt dat /usr/local/bin voorrang heeft.

Voeg eens het volgende aan het plist-bestand toe:

code:

<key>EnvironmentVariables</key>
<dict>
    <key>PATH</key>
    <string>/usr/local/bin:/usr/bin:/bin</string>
</dict>

Daarmee zou het Python-script met deze omgevingsvariable moeten worden uitgevoerd, aangenomen dat pyOpenSSL inderdaad zo werkt.

[Njay]

Eitot schreef op zondag 07 augustus 2016 @ 00:55:
Waarschijnlijk ligt het probleem in het feit dat root /usr/local/bin/openssl gewoon negeert. /usr/local/bin is een tertiaire locatie die pas na /usr/bin en /bin komt en aangezien OpenSSL 0.9.8 dus al in /usr/bin/openssl aanwezig is, zal /usr/local/bin/openssl nooit worden uitgevoerd. Als user zul je dat probleem niet hebben, omdat de installatie van Homebrew er al voor zorgt dat /usr/local/bin voorrang heeft.

Voeg eens het volgende aan het plist-bestand toe:

code:

<key>EnvironmentVariables</key>
<dict>
    <key>PATH</key>
    <string>/usr/local/bin:/usr/bin:/bin</string>
</dict>

Daarmee zou het Python-script met deze omgevingsvariable moeten worden uitgevoerd, aangenomen dat pyOpenSSL inderdaad zo werkt.

Aan de plist van sickrage ?

En thx voor je hulp alvast

Dit las ik net op een site

I never consciously set the SR user, I suppose it's due to the plist auto start method. My fix was to create the plist in ~/Library/LaunchAgents instead of /Library/LaunchDaemons/, thereby autostarting sickrage as my user instead of root.

Zou dit ook kunnen helpen ?

[ Voor 14% gewijzigd door Njay op 07-08-2016 10:16 ]

[Eitot]

Njay schreef op zondag 07 augustus 2016 @ 09:37:
Aan de plist van sickrage ?

Ja. Het voorbeeld dat op die door jouw genoemde website wordt gegeven.

Njay schreef op zondag 07 augustus 2016 @ 09:37:
Dit las ik net op een site

I never consciously set the SR user, I suppose it's due to the plist auto start method. My fix was to create the plist in ~/Library/LaunchAgents instead of /Library/LaunchDaemons/, thereby autostarting sickrage as my user instead of root.

Zou dit ook kunnen helpen ?

Ja, dat kan natuurlijk ook, mits het programma ook als user kan worden uitgevoerd. Ik vind het eerlijk gezegd nogal dubieus en behoorlijk onveilig om een dergelijk script permanent als root uit te voeren, al helemaal als het een poort naar buiten opent. Het is een risico.

[Njay]

Eitot schreef op zondag 07 augustus 2016 @ 12:15:
[...]


Ja. Het voorbeeld dat op die door jouw genoemde website wordt gegeven.


[...]


Ja, dat kan natuurlijk ook, mits het programma ook als user kan worden uitgevoerd. Ik vind het eerlijk gezegd nogal dubieus en behoorlijk onveilig om een dergelijk script permanent als root uit te voeren, al helemaal als het een poort naar buiten opent. Het is een risico.

Je antwoorden zijn helder ! ik zal jou plist methode eerst proberen.

als windows gebruiker heb ik behoorlijk wat lopen schelden toen ik hier mee bezig was ik begreep maar niet waarom sickrage weigerde de juiste openssl versie te lezen, ik begrijp dus nu dat sickrage als root wordt uitgevoerd door dat plist script en openssl als root nog naar de oude dir kijkt

klopt dit?

nogmaals many thx !

[Eitot]

Njay schreef op zondag 07 augustus 2016 @ 12:42:
ik begrijp dus nu dat sickrage als root wordt uitgevoerd door dat plist script en openssl als root nog naar de oude dir kijkt

klopt dit?

sudo nano /Library/LaunchDaemons/sickrage.plist

Deze opdracht bewerkstelligt dat een ‘launch daemon’ wordt toegevoegd die bij het starten van de computer wordt uitgevoerd. Launch daemons worden standaard als root uitgevoerd (/Library/LaunchDaemons is ook eigendom van root, net als hier het bestand sickrage.plist), tenzij anders wordt vastgelegd. In tegenstelling tot een ‘launch agent’ wordt een daemon vóór het inloggen uitgevoerd. Je kunt echter ook een daemon als een bepaalde gebruiker uitvoeren:

code:

<key>UserName</key>
<string>mijngebruikersnaam</string>

[Njay]

Eitot schreef op zondag 07 augustus 2016 @ 14:23:
[...]

sudo nano /Library/LaunchDaemons/sickrage.plist

Deze opdracht bewerkstelligt dat een ‘launch daemon’ wordt toegevoegd die bij het starten van de computer wordt uitgevoerd. Launch daemons worden standaard als root uitgevoerd (/Library/LaunchDaemons is ook eigendom van root, net als hier het bestand sickrage.plist), tenzij anders wordt vastgelegd. In tegenstelling tot een ‘launch agent’ wordt een daemon vóór het inloggen uitgevoerd. Je kunt echter ook een daemon als een bepaalde gebruiker uitvoeren:

code:

<key>UserName</key>
<string>mijngebruikersnaam</string>

Thanks again ! ik ga donderdag weer aan de slag met het systeem.

zal tijdens de installatie stappen het plist aanpassen met jou regels en dan weer proberen !

[Njay]

Eitot schreef op zondag 07 augustus 2016 @ 14:23:
[...]

sudo nano /Library/LaunchDaemons/sickrage.plist

Deze opdracht bewerkstelligt dat een ‘launch daemon’ wordt toegevoegd die bij het starten van de computer wordt uitgevoerd. Launch daemons worden standaard als root uitgevoerd (/Library/LaunchDaemons is ook eigendom van root, net als hier het bestand sickrage.plist), tenzij anders wordt vastgelegd. In tegenstelling tot een ‘launch agent’ wordt een daemon vóór het inloggen uitgevoerd. Je kunt echter ook een daemon als een bepaalde gebruiker uitvoeren:

code:

<key>UserName</key>
<string>mijngebruikersnaam</string>

Nou het werkt !

de plist toevoegen onder:

sudo nano /Library/LaunchDaemons/sickrage.plist
Updaten met brew en openssl

en klaar !

ik wil iedereen bedanken voor de hulp ! echt prachtig al die kennis hier