Revising the TM351 VM, I’ve started looking at not running everything as root, setting up an oustudent user and various service users, or services run as the oustudent user.
The key difficulty is trying to give a student enough permissions to run things we need them to run (which may require cerain sudo level privileges). We also need to have a way of giving students enough permissions to fix things if they break. (Our use of Vagrant provides one way round this – we may be able to ship fixes via a new Vagrantfile.)
As a complete novice to Linux sys admin when it comes to security and setting permissions groups, I turned to Twitter for a bit of lazy training. H/T to @isotoma for picking up on this:
This got me wondering about ways of “not” teaching… many academics are loath to share work in progress lest it contains errors. There are a couple of reasons for this: 1) don’t look stupid; 2) an assumed contract of trust whereby what academics say is taken on trust as being somehow true.
The above dialogue breaks that: my first, publicly shared, tweet presents a belief I’ve come to and want to check, but that contains a misunderstanding; this is then corrected by a practising expert. I try to explain back my new understanding and the expert further clarifies a best case. In response I try to “teach back” again my new understanding.
This is all very Paskian Conversation Theory with the twist that me (the learner in the conversation) is actually supposed to be a university teacher(?!), and the teacher in the conversation is a real, practising expert.
OU teaching materials actually embody elements of this. Print materials include SAQs (self-assessment questions) which, as part of the hidden reveal answer (in old school print books, the answer is in the back of the book; in new elearning money, you click to reveal the answer) include not only a statement of the correct answer but also examples of anticipated wrong answers, with a description of why they’re wrong. This “tutor at the side” explanation is a key part of the OU SOL (supported open learning) model (at least, as I understand it). You try to imagine sitting by the student, who tries the question, and gets a wrong answer; you then try to help them see why it’s wrong and point them in the right direction.
In the world of the web, and universal access to information, courses provide one way of accessing a structured route through a topic that help you construct an understanding of it. But so too, I think, does following expert learners (folk expert in learning) who record and reflect back on their learning a few steps ahead of you.
As to anticipating wrongness, I’m always reminded of an OU residential school I used to be a demonstrator for when I was a full time OU PhD student (I have a lot to thank the OU for…): the summer school, D309 Cognitive Psychology taught psychologists enough Prolog in a day to build a simple model of a columnar addition (example – I forget the original references nearly 25 years on!). As primary school teachers know, there are certain buggy rules that learners have that give understandable incorrect answers.
Trying to identify buggy rules is one of the things we try to pick up on in SAQs, trying to find ways to teach prior to the SAQ than pre-empt the buggy rule and maybe demonstrate how it’s possible and why it’s wrong forms part of the prior explanatory material. (That said, showing “wrong” ways of doing things has it’s own risks… learner’s may misremember the wrong explanation as being the correct one…)
More generally, here’s a reflection on my own practice: rather than trying to become an expert in something, I spend my days trying to learn things …
Being an expert can make teaching harder in some respects because you start to suffer from the expert’s blind spot and have to work hard at scaffolding explanations to help novices construct their own understanding. If you flip from being a teacher to someone who is trying to facilitate learning, this helps the learner too…
Being a learner-intending-to-teach-on makes you keenly sensitive to your own misconceptions and hard-to-get-your-head-round hang-ups. There is the problem of knowing (as a self-directed learner) when you have understood something though. Which is where trying to build things comes in as a more if intrinsic confirmation: if the thing doesn’t work, you’ve done it wrong / don’t understand it right. Sharing on your work for review (which in formal academia means submitting for peer review) is a way of trying to get extrinsic corroboration that you have understood / explained something correctly.
PS Meanwhile, last night, I twigged on a way of setting “enhanced” permissions on a usergroup, largely via Stack Overflow, which is an excellent source of novice question/expert answer knowledge.
My lazy option would be to just give ’em everything…
echo 'oustudent ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
Then they can act as root, without password, via sudo. But thats cheating… ;-)
Instead, I noticed you can set enhanced permissions in the
/etc/sudoers file, which I can do as part of the setup:
#Add user to mongodb group usermod -a -G mongodb oustudent echo ''' #Grant permissions on certain commands %mongodb ALL=NOPASSWD: /usr/bin/killall mongod %mongodb ALL=NOPASSWD: /usr/bin/killall mongos %mongodb ALL=NOPASSWD: /bin/systemctl restart mongodb %mongodb ALL=NOPASSWD: /etc/mongo-shards-down %mongodb ALL=NOPASSWD: /etc/mongo-shards-up''' >> /etc/sudoers
PPS The all points call for voluntary redundancies went round earlier this week. Depending how things turn out, I may need to start looking for new paying ways of not teaching soon:-(