Refinements master
authorMartin Pitt <martin@piware.de>
Sun, 19 Jan 2020 11:18:30 +0000 (12:18 +0100)
committerMartin Pitt <martin@piware.de>
Sun, 19 Jan 2020 11:26:09 +0000 (12:26 +0100)
cockpit-auth-anywhere.md

index 3845cdedc961c592d4e32dc0464a765ceb6506ef..68449a00c66c2a3d8a490dcb6584cd7dac65d147 100644 (file)
@@ -55,7 +55,7 @@ resize2fs /dev/vg0/data1
 - But wait, you say -- want to admin that server over there, but not allowed to
   open new port and system service?
 - In larger environments it's impractical to install cockpit server on hundreds
-  of machines and using the login web page; better solution: piggyback on ssh
+  of machines and using the login web page; explain better solutions
 - Glimpse of how to customize how cockpit runs and how to authenticate to it
 :::
 
@@ -68,12 +68,12 @@ resize2fs /dev/vg0/data1
 
 :::notes
 - for configuring, extending, and embedding Cockpit you need to coarsely understand the components of it
-- this: simplest structure, what I just showed you and what you will most probably see the first time you try it
+- this: default structure, what I just showed you and what you will most probably see the first time you try it
 - all components in cockpit communicate to each other via a JSON protocol on standard pipes, usually stdio
 - this provides a lot of flexibility and extensibility, as we'll see shortly
 - browsers and JS only speak HTTP and WebSocket, and can't directly talk to Linux system APIs
 - so you always need a web server somewhere, cockpit-ws
-- ws roles: communicate with the browser for getting credentials: login page, krb negotiation, client cert
+- ws purpose: communicate with the browser for getting credentials: login page, krb negotiation, client cert
 - ws: deliver HTML/js content, connects JSON protocol on the WebSocket to pipes to the other components; runs as unprivileged system user
 :::
 
@@ -85,8 +85,8 @@ resize2fs /dev/vg0/data1
 - forward JSON pipe to session leader
 
 :::notes
-- need some root helper to actually start session: use creds from ws to start PAM login session, connect pipe to it
-- standard is cockpit-session: very small, auditable
+- need some helper to actually start session: use creds from ws to start PAM login session, connect pipe to it
+- standard is cockpit-session: very small, auditable suid root helper
 - but doesn't have to be, that's the flexible part
 :::
 
@@ -111,9 +111,8 @@ nothing Cockpit specific running outside of the user session
 
 :::notes
 - ws and the login session don't need to run on the same machine
-- cockpit-session is meant to be customizable for your purposes
-- most obvious replacement is to let ssh start a session; that already does the
-  PAM bits and forward its initial stdio to the session lead; it would just
+- most obvious replacement of session helper is ssh; that already starts
+  sessions, does the PAM bits and forwards its initial stdio to the session lead; it would just
   launch cockpit-bridge instead of bash
 - browser: go to Dashboard, add cockpit.dev:2201
 - interesting property: nothing Cockpit specific running in the system, no ws,