[poky] [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Tian, Kevin]

> From: Wold, Saul
> Sent: Tuesday, February 01, 2011 8:31 AM
> 
> On 01/27/2011 05:18 PM, Tian, Kevin wrote:
> >> From: Wold, Saul
> >> Sent: Friday, January 28, 2011 8:34 AM
> >>
> >> On 01/27/2011 04:07 PM, Tian, Kevin wrote:
> >>>> From: Wold, Saul
> >>>> Sent: Friday, January 28, 2011 2:00 AM
> >>>>> +
> >>>>> +pkg_postinst_${PN} () {
> >>>>> +	if [ "x$D" != "x" ] ; then
> >>>>> +		exit 1
> >>>>> +	fi
> >>>>> +
> >>>>> +	# below setting is necessary to allow normal user using crontab
> >>>>> +
> >>>>> +	# add 'crontab' group and setgid for crontab binary
> >>>>> +	grep crontab /etc/group || addgroup crontab
> >>>>> +	chown root:crontab /usr/bin/crontab
> >>>>> +	chmod 2755 /usr/bin/crontab
> >>>>> +
> >>>>> +	# allow 'crontab' group write to /var/spool/cron
> >>>>> +	chown root:crontab /var/spool/cron
> >>>>> +	chmod 770 /var/spool/cron
> >>>>> +
> >>>>> +	chmod 600 /etc/crontab
> >>>>>     }
> >>>> Kevin,
> >>>>
> >>>> I am going to hold off pulling this and the at changes.
> >>>>
> >>>> Is there a specific reason that you are creating this as a post install
> >>>> operation for the permission management, both this and the at recipes
> >>>> are doing this.  Please remember that adding additional items that run
> >>>> at first boot slow things down.
> >>>>
> >>>> Is it possible to run these permission changes at actual install time,
> >>>> instead of on the target.
> >>>>
> >>>
> >>> I thought about this when baking the patch, and finally went to this way
> >> because
> >>> there's chown operation and new group needs to be created. This has to
> be
> >> done
> >>> on the target, as you'll see in other similar recipes like dbus, hal, ...
> >>>
> >> Since this is a similar theme, is there a bbclass or method that could
> >> be written in order to handle adding users/groups to the passwd/group
> >> file during sysroot creation time, prior to packaging?
> >>
> >> Will pseudo handle this correctly?
> >>
> >> Maybe for 1.0 we go this route, but we should think more about this, in
> >> order to create the users and groups we need.
> >
> > Yes, we can think more about it. The less postinst works, the better.
> >
> > But generally speaking, group/permission operations in my observation are
> > quick in the 1st boot. There're other postinst being heavy. :-)
> >
> The more you add to 1st boot that could be done during rootfs creation
> will always add more time, it's better to do it at rootfs time if possible.
> 
> Will you be-able to modify this for 1.0 M3?  If not will there be a plan
> for M4 or 1.1?
> 

Not for 1.0 M3. I would think 1.1 is better given that this task aims to improve
a long-standing issue (but I'll start it in M4 window). So would you accept this
patch (and also at) first since they are trying to fix functional issues? :-)

Thanks
Kevin