Thursday, August 05, 2021
After migrating an Ubuntu server from 16.04 to 20.04 I set up a user instead of root I am having trouble using sudo in cronjobs. My error message is as follows:
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
This question on AskUbuntu seems quite relevant. I am going to look into using the -S flag first. Before I try this I am going to make sure that my user is in the sudoers group as stated in the question. Ugh, when running visudo I opened the file using nano. I am going to change this to vim.
$ sudo update-alternatives --config editor
There are 4 choices for the alternative editor (providing /usr/bin/editor).
Selection Path Priority Status
------------------------------------------------------------
* 0 /bin/nano 40 auto mode
* 1 /bin/ed -100 manual mode
* 2 /bin/nano 40 manual mode
* 3 /usr/bin/vim.basic 30 manual mode
* 4 /usr/bin/vim.tiny 15 manual mode
* Press <enter> to keep the current choice[*], or type selection number: 3
Hang on. I am going to back up for a second. I know I could open up the sudoers file and add username ALL=(ALL) NOPASSWD:ALL. But now I am thinking to myself about whether or not I am adhereing to the principle of least privilege:
In information security, computer science, and other fields, the principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.
Does my user need to be added to sudoers in order to accomplish what we're doing? PoLP says that if we do need sudo access to run this cronjob then we should try to accomplish this in the Frist I am going to see what happens if we run the cronjob without sudo.
Alrighty. I can run the cronjob without sudo. But now I am seeing the old issue that I ran into of not being able to properly see the user's environment variables. Let's step back for a second and ask the question: What happens when a cronjob is run?
I am going to table that for a moment...
I realized that my env variables were not being cached but were being set in a couple of different locations: /etc/environment and /etc/systemd/system/gunicorn.service. But even if my ENV VARs are being set at the /etc level, why doesn't sourcing my .bashrc locally overwrite the environment variable? This may have something to do with the full .bashrc not getting executed (as per Cron job does NOT get the environment variables set in .bashrc). The syntax has changed, but I do indeed need to comment out "If not running interactively, don't do anything."
# # If not running interactively, don't do anything
# case $- in
# *i*) ;;
# *) return;;
# esac
That did it! Now I can run my cronjob without my user being a sudoer. Turns out that it was a holdover from when I was running the cronjob as root and I added sudo for some reason. Oh well. This blog would be over but django-markdownify is giving me grief for multiple lines of code so I am going to try to fix that quickly.
Right. So I am trying to configure the extension fenced_code_blocks. Seems like we got there by adding MARKDOWNIFY_MARKDOWN_EXTENSIONS = ['markdown.extensions.fenced_code']. I need to get syntax highlighting set up but I will leave that for later. Adios. Not bad for an hours work! Thanks for reading.