- Zero configuration
:::notes
-- TODO: check out bots in "make deps", add ./vm-run windows-10 to prep.sh
- Switch to Windows virt-viewer, open Edge, show Cockpit
- Quit virt-viewer
+- Move to local browser, enable mobile mode (Ctrl+Shift+M)
- Zero configuration so far, other than possibly installing cockpit pkg and enabling cockpit.socket
- In larger environments it's impractical to install cockpit server on hundreds
of machines and using the login web page
- 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
-- ws: deliver HTML/js content, translate WebSocket to JSON protocol; runs as unprivileged system user
+- ws: deliver HTML/js content, connects JSON protocol on the WebSocket to pipes to the other components; runs as unprivileged system user
:::
# Anatomy: cockpit-session
nothing Cockpit specific running outside of the user session
:::notes
-- TODO: start rhel7 VM in prep.sh, set hostname
- 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
- OAuth (Kubernetes)
- Foreman: included cockpit-ws with dynamic configuration
+TODO: foreman screenshot
+
:::notes
- Cockpit supports common authentication systems out of the box
- IdM is very common; if you have a krb ticket, you get a session immediately
machines
- runs a single cockpit-ws process on its server, and dynamically configures it
for selected target machine, seamless transition between Foreman and Cockpit
-- not enough time to demo all of this
+- not enough time to demo and explain all of this; just keep in mind that it's
+ possible
:::
# Custom authentication example
projects / talk-cockpit-auth-anywhere.git / blobdiff