.deb postinstall doe user ipv root

[Mar2zz]

Wat een lelijke titel, maar ik weet geen betere.

Ik heb een bash script geschreven dat een .deb-package maakt van sickbeard. Maar ik kom er bij 1 ding niet uit, hij installed de deb, dat gaat goed, maar ik wil sickbeard als de current user draaien, dus als de user die de deb installeert (via softwarecenter, dpkg of whatever).

Het postinstall script ziet er zo uit:

code:

#!/bin/sh

set -e

# change values in init.script
if grep -i 'SICKBEARD_USER' /etc/init.d/sickbeard > /dev/null
    then
    sed -i "s!SICKBEARD_USER!$USER!g" /etc/init.d/sickbeard
fi

#create pidfile permissions
if ! [ -d /var/run/sickbeard ]
    then
    mkdir /var/run/sickbeard
fi
chown -R $USER /var/run/sickbeard

#create datadir permissions
if ! [ -d ~/.sickbeard ]
    then
    mkdir ~/.sickbeard
fi
chown -R $USER ~/.sickbeard

# execute init.script
chmod +x /etc/init.d/sickbeard
update-rc.d sickbeard defaults
/etc/init.d/sickbeard start

En de bedoeling is dus dat $USER wordt vervangen door de huidige user, maar als ik de deb-package installeer dan wordt het vervangen door root. Ik heb mijn complete google-fu arsenaal erop losgelaten, maar ik weet dus niet hoe dat moet. Ik snap ook niet waarom ie direct met root gaat werken.

Het gekke is dat sickbeard dan wel weer de datadir en config.ini in ~/.sickbeard in de home-folder zet (dat is onderdeel van het init-script wat ik aan wil passen. Voor de volledigheid het initscript (het relevante stuk dan):

code:

############### EDIT ME ##################
# path to app
APP_PATH=/opt/sickbeard

# path to python bin
DAEMON=/usr/bin/python

# Path to store PID file
PID_FILE=/var/run/sickbeard/sickbeard.pid
PID_PATH=`dirname $PID_FILE`

# script name
NAME=sickbeard

# app name
DESC=SickBeard

# user
RUN_AS=SICKBEARD_USER

# data directory
DATA_DIR=~/.sickbeard

# config directory
CONFIG_DIR=$DATA_DIR/config.ini

# startup args
DAEMON_OPTS=" SickBeard.py -q --daemon --pidfile=${PID_FILE} --datadir=${DATA_DIR} --config=${CONFIG_DIR}"

############### END EDIT ME ##################

test -x $DAEMON || exit 0

set -e

if [ ! -d $PID_PATH ]; then
    mkdir -p $PID_PATH
    chown $RUN_AS $PID_PATH
fi

if [ ! -d $DATA_DIR ]; then
    mkdir -p $DATA_DIR
    chown $RUN_AS $DATA_DIR
fi

Iemand een idee waardoor dit komt dat SICKBEARD_USER door root wordt vervangen en hoe ik dat kan voorkomen? De .deb installeert verder prima en sickbeard werkt ook gewoon, maar ik wil het gewoon als user draaiende hebben.

[magistus]

Waarom niet gewoon een installatie zoals bijvoorbeeld bij hellanzb gedaan wordt?

Je wil dit echt niet (echt, geloof mij maar ), in je system-wide packagemanagement een package gemanaged voor 1 gebruiker (iig, niet voor de usecase zoals jij deze neer zet). Wat als naast Kareltje, ook Pietje graag met sickbeard aan de slag wil? Dan krijg je dus een probleem met 1 van de gebruikers.

Zorg dat je package gewoon system-wide installeerbaar is en zorg dat bijvoorbeeld /usr/bin/sickbeard een wrapper script is welke de user-specifieke zaken kan regelen. Als sickbeard maar 1 keer per systeem kan draaien (ken het pakket verder niet), maak dan een dedicated system-user en group aan waaronder iig de service kan draaien.

[Hero of Time]

En de reden dat je $USER root is, is omdat je moet installeren met root. Dus sudo dpkg -i sickbeard resulteerd altijd in een $USER met root. Dat je ~, of $HOME variabele niet verandert omdat door het gebruik van sudo. Je hele shell verandert namelijk niet, alleen je ID. Doe maar eens een sudo echo $HOME. Vreemd genoeg geeft hetzelfde voor $USER wel de user die je sudo uitvoert, niet root. Maar om een of andere reden wordt het script dus anders aangestuurd en is het alsnog root.
Misschien dat je hiermee met Google wat verder kan komen. Maar wat magistus zegt is stukken beter, laat 't een eigen dedicated gebruiker maken, net zoals vele andere deamons draaien (apache heeft www-data, squid heeft proxy, etc).

[Mar2zz]

magistus schreef op maandag 03 oktober 2011 @ 23:29:
Waarom niet gewoon een installatie zoals bijvoorbeeld bij hellanzb gedaan wordt?

Je wil dit echt niet (echt, geloof mij maar ), in je system-wide packagemanagement een package gemanaged voor 1 gebruiker (iig, niet voor de usecase zoals jij deze neer zet). Wat als naast Kareltje, ook Pietje graag met sickbeard aan de slag wil? Dan krijg je dus een probleem met 1 van de gebruikers.

Zorg dat je package gewoon system-wide installeerbaar is en zorg dat bijvoorbeeld /usr/bin/sickbeard een wrapper script is welke de user-specifieke zaken kan regelen. Als sickbeard maar 1 keer per systeem kan draaien (ken het pakket verder niet), maak dan een dedicated system-user en group aan waaronder iig de service kan draaien.

Klinkt goed, maar wat bedoel je precies met wrapperscript? De datadir en configdir optie die in sickbeard script zitten zorgen in principe al voor 1 package voor multiple users, alleen het init script zit dan vast aan 1 user. Ideaal zou zijn natuurlijk als gebruiker a inlogt dat zijn 'eigen' sickbeard gaat draaien, met eigen config en data, en als gebruiker b inlogt dat ook gebeurt.

Op zich zou een specifieke gebruiker wel prima oplossing zijn, dan moet ik ff leuke naam verzinnen, want het bash-script dat die .deb-files maakt is vrij makkelijk aan te passen naar andere github/svn applicaties. maar dan vervalt toch het multiple-user systeem?

[magistus]

Sickbeard is (momenteel) niet als multi-user te installeren, zie ook https://code.google.com/p/sickbeard/issues/detail?id=578.
Je hebt dus 2 opties:
1) Sickbeard als system-wide service:
Maak een systeemuser en group aan (bv: sickbeard:sickbeard) Maak vervolgens (handmatig!) de gebruikers lid van de sickbeard groep (let wel dat sickbeard dan bestanden, welke voor groepsleden bewerkbaar moeten zijn, wegschrijft met read- en writerechten waar nodig)

2) Doe hetzelfde als bij 1, maar disable het init-script door bijvoorbeeld een etc/default/sickbeard configuratiebestand te gebruiken. Plaats vervolgens een script in /usr/bin welke SickBeard.py (gokje, geen idee wat de juiste methodiek is) met de juiste opties start. In dit script kan je, mocht sickbeard dit al niet zelf kunnen, de $USER wel uit de environment van de startende gebruiker krijgen.

[Mar2zz]

Handmatig lid maken van groepen moet ik niet willen. Ik maak zo een deb-file zodat het installeren voor newbies makkelijker wordt op xbmc-live machines en via een eventuele repo ik upgrades kan aanbieden (ook aan mezelf). Ik draai gewoon tweewekelijks ofzo dat bashscript met een cron die de laatste sickbeard afhaalt van github en omzet naar een .debfile en laat het in de repo zetten. Ik moet dan alleen nog uitzoeken hoe ik een repo opzet.

Volgens mij kan het ook anders. Ik denk dat het niet uitmaakt dat sickbeard als root draait dus ik heb me erbij neergelegd. Ik heb het als volgt gedaan. Sickbeard zelf installeert in /opt/sickbeard en de data en configfiles worden in /etc/sickbeard/* gezet. Zo overleven ze upgrades.

Als ik het goed heb kan sickbeard gewoon als root gedraaid worden omdat die file altijd leesbaar voor ieder maakt. Dit is op een server ook prima. edits van configfiles met het handje moeten dan via sudo, maar dat zal een 'newb' toch niet willen, de configuratie kan gewoon via de webinterface gedaan worden.

Ik heb 'm nu op mijn live masjien geinstalled, en het ziet er goed uit. Die /usr/bin/sickbeard is toch een file waarmee je sickbeard kan typen op de command line overal die dan vervolgens sickbeard start?
Dan is zoiets toch voldoende in /usr/bin/sickbeard:

code:

#!/bin/sh
sudo /etc/init.d/sickbeard $1 &&
exit 0

sickbeard geeft dan Usage: /etc/init.d/sickbeard {start|stop|restart|force-reload}

heb van de /usr/bin-file in case vanalles gezet zodat er wat meer mogelijkheden zijn, zoals bijvoorbeeld sickbeard git-update, die de package bijwerkt vanuit git.

[ Voor 5% gewijzigd door Mar2zz op 04-10-2011 21:56 . Reden: /usr/bin aangepast. ]

[Hero of Time]

Dan nog zou ik Sickbeard als non-privileged user draaien, zoals Apache webserver dat ook doet via www-data. De config files kan je een user of group owner geven naar sickbeard, welke dan schrijfrechten erop heeft. Ieder ander zal dan via sudo moeten werken, omdat hij/zij niet de eigenaar is van de configuratiebestanden.
Nu zet je in feite het hele security model van Linux wijd open en dat is de slechtste oplossing die er is (vziw, er zal vast wel ergere dingen zijn). Een beveiligingslek in sickbeard kan nu grote gevolgen hebben.

Ow, en je script hoeft geen '&& exit 0' te hebben. Het roept tenslotte een ander script aan en sluit zelf af. En anders kan je altijd gewoon '&' neerzetten. Mocht je meerdere parameters mee kunnen geven, kan je $@ gebruiken .

[Mar2zz]

Ok thx.
Ik heb het nu zover dat ie een user aanmaakt met de postinstall:

code:

#create user
useradd -M -r -c "Autocreated by sickbeard installer" -d /etc/sickbeard sickbeard

Wat resulteert in:
sickbeard:x:999:999:Autocreated by sickbeard installer:/etc/sickbeard:/bin/sh

Alleen krijg ik tijdens het starten van de app een error dat ie de default browser niet mag starten. Wat wel logisch is, en lijkt me dus al een verbetering. Maar hoe onderdruk ik die error? Sickbeard werkt verder wel goed als ik naar localhost:8081 ga dan werkt het verder prima.

Dit is de error en hij houdt de terminal vast, alleen met ctrl+c, krijg ik de prompt weer:

code:

No protocol specified

(chromium-browser:2289): Gtk-WARNING **: cannot open display: :0.0

Zoals je merkt is an amateur speaking.

[Andre-85]

Ik weet niet zeker of ik je goed begrijp, en heb het topic slechts vluchtig gelezen. Toch even mijn 2 cents

De error kan je onderdrukken door op de regel waar je de app start af te sluiten met

code:

 &> /dev/null

Dit redirect stout en sterror naar /dev/null. Het "vasthouden van de terminial" kan je voorkomen door de regel af te sluiten met '&'

code:

 &> /dev/null &

Dit start de applicatie in de background.

Ik hoop dat je hier verder mee komt. Een ubuntu repo zou ik wel geslaagd vinden

[Mar2zz]

Dat werkt helaas niet.

Wat sickbeard doet @ start is met een clean config de browser proberen te starten. Dat is irritant, aangezien je daar op headless servers ook niets aan hebt. Dus eigenlijk zou sickbeard zelf die check moeten doen of er wel of niet een browser aanwezig is.

Als ik als sickbeard user draai dan krijg ik problemen met rechten. stel dat je sickbeard zo configureert dat je wilt dat ie tvshows in je eigen /home/user/Video's zet, dan kan ie die shows niet aanmaken als je als sickbeard user draait. Die heeft die rechten niet. Als ik 'm als root draai dan zal ie die map wel aanmaken, maar ja, die is dan geowned door root.

Ik denk dat ik beter voor de sabnzbd en transmission approach kan gaan, werken met een /etc/default/sickbeard en dan daarin dingen laten zetten als user, poort en config-dir, en dan via postinstall de editor launchen met dat bestand, zodat users dat gelijk kunnen aanpassen. En daarna pas starten.

Ik ben ook nog niet tevreden over die systemwide /usr/bin/sickbeard. daarvoor is nog het sudo wachtwoord nodig, en dat wil ik niet, andere services werken ook niet zo, dus dat wil ook nog aanpassen.

Denk je ook ff een deb-file in elkaar te flansen. Nadat ik de filestructuur ervan dacht te kennen dacht ik dat ik er wel was

[Mar2zz]

ff een update, ik denk dat ik er ben.

't was een hele tour, maar dit lijkt te werken. Ik heb een systemwide executable geschreven voor in /usr/bin. In principe kan elke user (ook zonder rootrechten) die gebruiken om sickbeard te starten. Alleen dan wordt er een 'eigen instance' gestart, met config en dergelijke in de eigen home-directory. Dit is wel te overriden met command line opties zoals sickbeard --config=/pad/naar/config. Dit geldt ook voor poort, pidfile, datadir en dergelijke.

sickbeard zelf zit veilig in /opt/sickbeard, waar alleen root aan kan zitten.

De daemon is alleen te configureren als je rootrechten hebt. De settings daarvoor heb ik apart gezet in /etc/default/sickbeard. die settings worden geimporteerd in /etc/init.d/sickbeard en die gaat met die settings @ start draaien. Wel checkt ie eerst of er een user is gezet in /etc/default/sickbeard.

In principe is het ook mogelijk om verschillende instances naast elkaar te laten draaien, door het initscript te laten verwijzen naar een andere settingsfile, met andere poort, pid, data en configdir, maar dat is meer iets voor de tweakers die geen debfiles hoeven.

de /usr/bin/sickbeard is een bashscript die

/usr/bin/python /opt/sickbeard/SickBeard.py $@

doet. Met een flinke case-eval heb ik ervoor gezorgd dat de input niet afwijkt van de mogelijkheden van sickbeard, en zo kon ik er ook nog een leuk helptekstje bij schrijven ook voor sickbeard --help.