Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split slides into roles: Administrator & Participant #2

Open
vincentarelbundock opened this issue May 28, 2021 · 4 comments
Open

Split slides into roles: Administrator & Participant #2

vincentarelbundock opened this issue May 28, 2021 · 4 comments

Comments

@vincentarelbundock
Copy link
Collaborator

vincentarelbundock commented May 28, 2021

Instead of "Simplest Demo: Multi-User", we could present the two "roles" with working code. Move the byobu and emacs -nw discussion to the "Administrator" slides or the "Other tricks" section.

Use real working code with new username instead of a "git" user.

Demo: Administrator

Working commands to:

  1. Create temporary users and groups
  2. Create working directory with "secure" permissions
  3. Launch tmux session

Demo: Participant

Working commands to:

  1. SSH into the remote box
  2. Join the tmux session
@eddelbuettel
Copy link
Member

  • Agree on removing git. As I tried to say, that is (currently) the only other user on the machine in question. We probably need a 'at least for a few hours' semi permanent machine with accounts vincent, grant and dirk all of whom a part of group 'project42' (or any other name). Then is it just chgrp project42 sockethere; chmod g+rw sockethere.

  • Strong disagree on 'create temp user and groups'. That is orthogonal to what we want to talk. Minimize friction. Assume users as given.

  • Mild disagree on tmux / byobu given my t4 history and it byobu focus. Plus, byobu is tmux (unless you set it up to use screen which is non default)

@vincentarelbundock
Copy link
Collaborator Author

vincentarelbundock commented May 28, 2021

I'll make one last attempt to convince about users and groups and then drop it.

IMO, this is absolutely not orthogonal. Ideally, the slides would include A-to-Z for both the Admin & Participant sides. The cost of including user+group management commands is essentially nil: 2 lines of code?

And the benefits are positive, I think: at least some members of the target audience work on Windows most of the time, and don't have a much of a clue about user permissions and groups on linux. Maybe they SSH into a cluster once in a while, but they're are not admin there. Or maybe they spin a linode to do some computations, but create their sudo-capable username from the web interface. We want to show them that it's very easy to be an "Admin" and add participants without too much privilege to a shared byobu.

[Dropping this now]

@eddelbuettel
Copy link
Member

eddelbuettel commented May 28, 2021

I want to minimize barriers to entry. Having a machine with shared accounts is one. I hope we can take it as given.

One mental model I have is work as, e.g., back in the day when I visited Queen's econ dept as a grad student. Old school large Unix box. Multiple accounts and users. I am not the one creating accounts -- but I am the one who could be inviting someone else into my shared tmux/byobu session. And that would have worked then over a shared dial-up telnet or ssh session.

In other words, I don't want to do a tutorial that starts with "here is how you order your workstation. here is how you install ubuntu. here is how you add users". All (and I really mean all) of this has to be a given. We focus just on the cherry here and ignore that the cake was baked, the flour was milted, the wheat was grown etc

Am I making sense? I.e. I don't plan to bore listeners with all details we three have to deal with to do the video. That is a separate topic.

@eddelbuettel
Copy link
Member

It would also make the roles 'less different'. Simple 'he/she who starts the session, and sets the socket to allow others' and 'all others who join'. A bit like zoom where the someone 'owns' the session and may have to turn screen share on for participants. I.e. mental distance to unix model of god (root) and everybody else. It's all in userspace, really. (If everything is installed etc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants