- 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
:::
:::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
:::
- 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
:::
:::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,