:::notes
- Conceptually: Linux session running in a web browser; technically very similar to ssh/VT/GNOME login
-- Aimed at admins who are new to Linux, e. g. coming from the Windows world and familiar with the concepts, but not Linux terminology
-- but also to experienced ones for infrequent tasks; not just setup, but also investigating “what is wrong with this machine”
+- Tool for experimenting, learning, troubleshooting, and doing infrequent tasks
:::
```
:::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
- Zero configuration
:::notes
+- being web based makes this server UI available to places that you
+ traditionally don't reach with ssh
- Switch to Windows virt-viewer, open Edge, show Cockpit
- Quit virt-viewer
- Move to local browser, enable mobile mode (Ctrl+Shift+M)
:::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
- 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: deliver HTML/js content, connects JSON protocol on the WebSocket to pipes to the other components; runs as unprivileged system user
:::
- can run in container
- no ws on critical machines, don't trust cockpit-session
- switch to browser; log out, use "connect to" for cockpit.dev:2201
+- finish the demo script, press Enter
:::
# Other authentication setups
- OAuth (external embedding)
- 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
present them to the web server; latest Cockpit versions supports that
- Foreman has a "Web Console" button; interesting case for seamless transition
between Foreman and Cockpit
+- Show video
- already has ssh to all maintained machines
- runs a single cockpit-ws process on its server, and dynamically configures it
for selected target machine
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
:::
- 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
projects / talk-cockpit-auth-anywhere.git / blobdiff