[crontab] Not authorised?

[Verwijderd]

Op dit moment ben ik bezig met het implementeren van een SNMP monitoring tool (cacti)voor een netwerk. Ik maak gebruik van Solaris 9.

Om alle servers goed te kunnen monitoren is het noodzakelijk dat er een "cron" aangemaakt wordt wat om de 5-10 minuten een php script aanspreekt.

Ondernomen stappen:

- user aangemaakt (cacti)
- user rechten gegeven op de directory van het uit te voeren script (als test :chmod 777)

- user toegevoegd aan /etc/cron.d/cron.allow)
- gecheckt of hij voorkwam in cron.deny

- PATH variabele toegevoegd aan het .profile van de user zodat de bin PHP overal aangesproken kan worden.

Als ik nu inlog met de betreffende user en daar /etc/cron probeer uit te voeren krijg ik de volgende melding

code:

# su - cacti
$cd /etc
$ ./cron
! you are not authorized to use cron.  Sorry. Thu Nov 17 10:30:29 2005
! ******* CRON ABORTED ******** Thu Nov 17 10:30:29 2005

Ik vraag me af waar ik nog meer rechten moet verlenen aan de user om cron te mogen uitvoeren.

[RagaBaSH]

even googlen wees op een gebruiker van de unix.com forums die het aan de praat kreeg door de cron.allow file te verwijderen. misschien ligt daarin de oplossing (zoals altijd wel alles backupen )

[Verwijderd]

cron.allow stond niet op het systeem. Heb deze handmatig aangemaakt.

Op een site las ik dat als deze file er niet was dat iedereen gewoon rechten zou moeten hebben om dit uit te voeren.

/etc/cron.d/cron.allow

ik heb wel degelijk google gebruikt BTW , misschien heb ik iets over het hoofd gezien.

[RagaBaSH]

ik zag idd bij mijn google search dat cron.allow niet standaard meegeleverd moet worden.
Maar ik zal dat er een gebruiker was die het probeerde met en zonder cron.allow.
Met cron.allow file aanwezig kreeg hij dezelfde error als jij, zonder niet.

bovendien kan je je cron systeem nog steeds aardig secure houden met alleen cron.deny.

het was ook geen aanval op je voorwerk (wat m.i. overeenkomt met wat er in de solaris 9 admin manual staat over crontab.. dus gewoon de stappen een voor een doorgelopen). maar meer een vraag van, goh. probeer eens zonder, dan weet je iig dat het probleem daar wel/niet ligt.

[Paul]

Nu ben ik totaal onbekend met Solaris dus misschien wijkt de cron-setup daar radicaal af van die van Debian, maar draait de cron-daemon niet al sinds boot en is het enige wat je nu nog moet doen crantabs aanmaken?

Zo ja: su of inloggen als die cacti-user en dan "crontab -e" uitvoeren

[ Voor 17% gewijzigd door Paul op 17-11-2005 14:34 ]

[Soultaker]

Volgens mij heeft Paul Nieuwkamp gelijk.

Verder helpt het niet om paths in je .profile te zetten; v.z.i.w. wordt die niet geparsed door cron. Wél kun je een path opgeven in je crontab zelf.

[Aapzak]

Over environment opnemen in cron, ik heb een script die bijv. Oracle libraries nodig heeft, je enviroment declareer je heel simpel:

code:

ORACLE_HOME="/U01/app/oracle/product/9.2.0"
LD_LIBRARY_PATH="/U01/app/oracle/product/9.2.0/"
41 * * * * /usr/bin/perl /home/path/to/script.pl >> /home/path/to/.cronlog

Dit werkt voor mij. Echter geen idee over je basisvraag, waarom kan je cronjob niet afgevuurd worden.

edit:
ik twijfel over je testmethode. Waarom zou de user cacti /etc/.cron runnen? Je moet in je homedir staan, zorgen dat je favo editor gezet is 'export EDITOR=vi' en dan doe je 'crontab -e'.
Daarin zet je je cronjobs die dan gerunt moeten kunnen worden, eventueel voorafgegaan door environment settings.
Ik kan er natuurlijk naast zitten, maar volgens mij mogen alle users standaard cronjobs aanmaken en zou het gewoon moeten werken.

edit2:
ik heb nu net op een standaard Solaris 9 systeem een cronjob aangemaakt op de manier zoals ik boven beschreef. Gewoon elke minuut een echo naar een file ofzo. Dat werkte bij mij wel, dus standaard staat cron aan voor users. En cronjob runt dus wel terwijl mijn user niet /etc/.cron mag runnen, dat is dus geen goede test lijkt me.

[ Voor 57% gewijzigd door Aapzak op 18-11-2005 09:40 ]

[Paul]

Na het aandachtig bestuderen van het stuk tussen code-tags denk ik er wel uit te zijn:
Je probeert een configuratie-bestand uit te voeren. Configuratiebestanden zijn niet executable -> execute-bits zijn niet geset -> User heeft "geen rechten" om dat bestand uit te voeren.

Je bent dus gewoon fundamenteel fout bezig. Ik zou zeggen, verdiep je eerst eens in het verschil tussen executables en configuratiebestanden ofzo

[Soultaker]

Een niet-executable file zou wel iets als 'permission denied' opleveren en niet zo'n uitgebreide, specifieke foutmelding. Ik heb net even op een SunOS 5.8 bak gekeken en een /etc/cron is wel degelijk een executable, die je als gewone gebruiker niet hoort te gebruiken.

Je hoort je crontab ook daar te editen met 'crontab -e' dus dat zal de TS wel gewoon fout doen. Zie 'man crontab' voor details.

[zomertje]

Ik sluit me aan bij de post hierboven: crontab -e
En via crontab -l kun je opvragen wat er nu al gescheduled is

[Paul]

Een file in /etc, niet /etc/init.d, is executable?

Dan zal ik de filosofie erachter wel niet snappen, eigenlijk vind ik /etc/init.d al krom (maak daar /sbin/init.d van of zo, de symlinkjes per runlevel (/etc/rc#.d) zou je nog als configuratie-iets aan kunnen merken, maar de scripts in /etc/init.d amper), maar ik dacht dat /etc voor config-files bedoeld was?

[Soultaker]

/etc/cron is een symlink naar /usr/sbin/cron.

Het idee is, denk ik, dat de keuze welke dingen wel en niet bij het booten gestart moeten worden een configuratie is en daarom moet dat in /etc zitten. Tot zover logisch, lijkt me? De instelling zelf voer je dan uit door de applicatie die je wil uitvoeren te symlinken in /etc. De executable zelf staat dan nog wel in /sbin of /usr/sbin (waar je 'm zou verwachten).

Maar ik ben het met je eens dat het gewoon raar is, want ik zie ook een /etc/init.d met een cron-scriptje wat /usr/sbin/cron direct aanroept. Geen idee welke van de twee nu gebruikt worden -- misschien is één van de twee een overblijfsel van een oudere SunOS versie?