X-Git-Url: https://piware.de/gitweb/?p=talk-cockpit-auth-anywhere.git;a=blobdiff_plain;f=cockpit-auth-anywhere.md;h=68449a00c66c2a3d8a490dcb6584cd7dac65d147;hp=59b2c152fc8efd94f59893307433c744661071c4;hb=HEAD;hpb=c277c4ac238af5f48c6f43989dbaf427c63bb063

diff --git a/cockpit-auth-anywhere.md b/cockpit-auth-anywhere.md
index 59b2c15..68449a0 100644
--- a/cockpit-auth-anywhere.md
+++ b/cockpit-auth-anywhere.md
@@ -6,7 +6,7 @@ email: mpitt@redhat.com
 date: DevConv.CZ 2020
 theme: Singapore
 header-includes:
- - \setbeameroption{show notes}
+ - \setbeameroption{hide notes}
 ...
 
 # Cockpit what?
@@ -31,7 +31,7 @@ resize2fs /dev/vg0/data1
 ```
 
 :::notes
-- for example, adding a new PV to an LV and resizing the file system you can spend some time coming up with these commands
+- for example, adding a new PV to an LVM and resizing the file system you can spend some time coming up with these commands
 - lots of possibilities for screwing up
 - you can do it simply and safely with Cockpit like this → go to local browser
 - Storage page, vg0 in Devices (top right), + in Physical Volumes, add sdb2
@@ -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,11 +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
-- browser only speaks HTTP and WebSocket, so you always need a web server, cockpit-ws
+- 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
-- ws roles: communicate with the browser for getting credentials: login page, krb negotiation, client cert
+- 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 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
 :::
 
@@ -84,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
 :::
 
@@ -110,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,
@@ -179,6 +179,7 @@ RequireHost=true
   Linux session, it knows who I am
 - put the whole auth structure inside out and instead run cockpit-ws as my user
   inside my session
+- open --local-session in shell
 - open localhost:9999 in firefox
 - alarm bells: exposes my session to a TCP port without any auth
 :::
@@ -203,13 +204,14 @@ RequireHost=true
 - suddenly you end up with a halfway decent desktop app
 - just the storage page, replacement for gnome-disks
 - cockpit-desktop podman
+- cockpit-desktop is small shell script, feel free to inspect and bend to your will
 :::
 
 # Conclusion
 
 - Authentication is very flexible
 - Works with zero configuration
-- Can be arbitrarily embedded
+- Can be arbitrarily embedded and customized
 
 :::notes
 - Cockpit provides a set of standard auth protocols that are being used in