Open gavanderhoorn opened 6 years ago
repo
deployments now also seem to run into this.
Some googling suggests this is a permission issue (this SE post fi): regular users are not allowed access to crontab
, unless they are listed in /etc/cron.allow
, which ~doesn't exist~ is empty on the VMs I deploy to.
Adding jenkins-agent
to it made the repo
deployment succeed.
@nuclearsandwich: are the EC2 instances you deploy to setup differently? Should we add jenkins-agent
to /etc/cron.allow
with puppet
?
Even after adding jenkins-agent
to cron.allow
, I get during deployment:
The user jenkins-agent cannot use this program (crontab)
after su - jenkins-agent
, crontab -l
returns no crontab for jenkins-agent
.
The puppet
run is successful though, which is strange, seeing as the crontab doesn't appear to have actually been created.
Adding jenkins-agent
to /etc/cron.allow
seems to resolve all issues.
On master
, this is not such a problem, as the user
for the cronjob is root
, which is always allowed to interact with cron. We do get the warning though.
See #189 for a potential fix.
I had the same issue on Ubuntu Server 16.04. Adding jenkins-agent
to /etc/cron.allow
worked for me as well.
@RonaldEnsing: removing the /etc/cron.allow
file (as mentioned in https://github.com/ros-infrastructure/buildfarm_deployment/pull/189#issuecomment-361389563) should also 'fix' this.
See #189 in general for some more context.
At some point during a
master
deployment, the following message was printed on the console:Haven't checked yet where this is coming from.
Interestingly: I've only seen this on this particular host, but afaict, it's the same Ubuntu Server 16.04
amd64
as I've used for all other deployments the past two weeks.crontab
is present on the system, so perhaps it's a permission thing.