sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
921 stars 126 forks source link

crontab doesnt work for users #58

Closed bvandermeersch closed 5 years ago

bvandermeersch commented 5 years ago

demouser@pi64 ~ $ crontabe -e 'var/spool/cron/crontabs' is not a directory, balling out.

Ive created new users and same thing.

Sees to work for root though.

sakaki- commented 5 years ago

Yes, I can confirm this, thanks for reporting. Seems to be an existing issue with cronie on Gentoo (I have just got the vanilla package installed on the image); to fix it, you could try the following suggestion from Kosmas (seems to work my end): https://forums.gentoo.org/viewtopic-p-4301855.html#4301855

(In particular note /var/spool/cron should be owned cron:root, not root:cron). There is no need for your regular user to be in the cron or crontab groups, I think.

gordio commented 5 years ago

@sakaki- but if cron:root you still can't edit this file (because you not in group root). Right?

sakaki- commented 5 years ago

@gordio you don't edit it directly though, but via the crontab program which is, iirc, setgid to group crontab. Kosmas' instructions also made this directory 755, so anyone could traverse it. /var/spool/cron is a directory: the files of interest are in /var/spool/cron/crontabs/<username> within it (the crontabs dir is owned root:crontab and the files within it <user>:crontab).

Anyway, I've just tried this on a fresh copy of the image: it seems that if instead of the above linked instructions from Kosmas, you simply add your regular user to the cron group, so:

pi64 ~ #  gpasswd -a demouser cron 

user cron editing works (upon next login to that user).

For this to work, leave the ownership of /var/spool/cron as root:cron.

If one of the two of you would be kind enough to check this, I'll make sure this is fixed in the next release of the image, which I'm just starting to prepare now.

bvandermeersch commented 5 years ago

Thanks for the fixes guys. I also have one other issue you may be able to help with.

I am unable to install the net-libs/nodejs package as well, I get a bunch of complaints about ssl package and have been unable to fix it. Mostly due to my lack of understanding of how emerge/gentoo handles package dependencies. Can you point me in the right direction?

sakaki- commented 5 years ago

@bvandermeersch -

this is a general Gentoo question (likely to do with the bindist USE flag, which is set globally on the image to restrict patent-encumbered and similar code, so it may be legally redistributed) so I recommend you post it to the ARM board of the Gentoo forums (here). It's a friendly forum and someone there will be able to help you get the package you want installed. Be sure to post a full log of the failed emerge, and the output of emerge --info, to your post.

hth, sakaki

sakaki- commented 5 years ago

@bvandermeersch - something like the below should work to get you started (if you post on the Gentoo forums someone there can give you more background as to what is going on here):

pi64 ~ # emaint sync --auto
pi64 ~ # echo -e '\n# disable bindist globally\nUSE="${USE} -bindist"' >> /etc/portage/make.conf
pi64 ~ # nice emerge -av --changed-use --with-bdeps=y dev-libs/openssl net-misc/openssh dev-qt/qtnetwork net-libs/nodejs

The emerge will compile locally, since obviously I cannot distribute -bindist packages from the binhost (that being the point of this particular USE flag).

hth, sakaki

bvandermeersch commented 5 years ago

@sakaki- thanks for pointing me in the right direction I have posted on the forums. The fix you have posted above did not work for bindist. Still have an array of issues. But im waiting for replys on that gentoo forums. Thanks.

sakaki- commented 5 years ago

@bvandermeersch - I saw your post on the Gentoo forums and have just responded there - you'll need to supply some more info to allow people there to be able to help you. Please see my post for details. Thanks! S.

sakaki- commented 5 years ago

I believe the original issue (crontab) is fixed now as of v1.3.0 of the image, by making demouser a member of the cron group (and amending the README accordingly re creation of new users). I have also noted the use of gpasswd -a <username> cron for users of older copies of the image, in the manual upgrade notes for v1.3.0.

Please re-open this issue if the problem persists. Thanks again for reporting!