027ec4d836
Between `build.js` and `file.js` we determine the location of `pkg` (and various tools that we need to invoke) in one of two ways, neither of them particularly good: - they're assumed to be relative to '.', which only works if ./build.js is invoked from the automake srcdir. That happens to be the case when pkg/Makefile.am does the invocation (it does a 'cd' first) but it breaks if you try to run build.js manually from a different directory. - redundantly, if `$SRCDIR` is set, this will be used in some (but not all) places Let's standardize on looking at `import.meta.dirname`. This is how node resolves imports, so it's pretty much guaranteed to be correct (or else the script itself wouldn't be running in the first place). This is an absolute pathname derived from argv[1] as passed to node (ie: build.js itself). For the qunit plugin, `import.meta.dirname` is the path of the plugin itself, which makes it perfect for finding the `.template.html.in` file located immediately adjacent to itself, saving some path gymnastics. During our computation to create `runtime-npm-modules.txt` we need to be careful: pathnames are based on `import.meta.dirname` now and are therefore always absolute: we need to adjust our logic for finding paths starting with `node_modules` to consider the relative pathname. |
||
|---|---|---|
| .cockpit-ci | ||
| .fmf | ||
| .github | ||
| containers | ||
| doc | ||
| examples | ||
| LICENSES | ||
| node_modules@10ee7c644b | ||
| pkg | ||
| plans | ||
| po | ||
| selinux | ||
| src | ||
| test | ||
| tools | ||
| vendor | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .gitignore | ||
| .gitleaks.toml | ||
| .gitmodules | ||
| .stylelintrc.json | ||
| antora-playbook.yml | ||
| AUTHORS | ||
| autogen.sh | ||
| build.js | ||
| configure.ac | ||
| files.js | ||
| HACKING.md | ||
| Makefile.am | ||
| package.json | ||
| packit.yaml | ||
| pyproject.toml | ||
| README.md | ||
| tsconfig.json | ||
A sysadmin login session in a web browser
What is Cockpit?
Cockpit is an interactive server admin interface. It is easy to use and very lightweight. Cockpit interacts directly with the operating system from a real Linux session in a browser.
Cockpit makes Linux discoverable, allowing sysadmins to easily perform tasks such as starting containers, storage administration, network configuration, inspecting logs and so on.
Jumping between the terminal and the web tool is no problem. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface.
You can also easily add other machines that have Cockpit installed and are accessible via SSH and jump between these hosts.
Installation
Note
An installation guide can be found at cockpit-project.org/running.html. Some systems may need extra work, read about it in our FAQ
Cockpit is available in numerous Linux distributions and is usually packaged as cockpit.
Flatpak 'Cockpit Client'
We also provide a Flatpak app called Cockpit Client which includes SSH login support to Linux servers.
Screenshots
| Light | Dark |
|---|---|
 |
 |
 |
 |
 |
 |
Contributors
To quickly make code contributions we have a HACKING.md that outlines the devel environment and running tests. For more in-depth we have a developer documentation that links to more resources about setting up the local environment, how designs are proposed, creating and running tests, and our overall contribution process.
Translations are managed in Weblate.
Security
Please see SECURITY.md.