cockpit-project / cockpit-project.github.io Goto Github PK

Messaging:

• Admin from your pocket (mobile)
• Learning tool (what can you do with your machine)
• Troubleshooting
• Custom admin UI
• Doesn't own your server (do stuff in parallel)
• Don't need to use the command line (but you can)
• Doesn't need a web server
• State of your server at a glance
• Junior admin friendly (It's not just for you, it's for your whole team)
• Use your own account
• Easy to install; it's in the big repos
• Uses native system APIs; uses systemd/sudo/polkit/networkmanager/firewalld/packagekit/etc.
• Write a UI for your server in minutes COMING SOON (not available yet)

The website needs a link to documentation.

GitHub pages now supports HTTPS for custom domains.

We should upgrade to HTTPS and make it the default.

More information at https://blog.github.com/2018-05-01-github-pages-custom-domains-https/

The W3C recommends a contrast ratio of 4.5:1 for most text, so that it is also readable for people who have various forms of vision deficiencies.

There's a tool to check if the contrast ratio is high enough: http://webaim.org/resources/contrastchecker/?fcolor=b4b7af&bcolor=ffffff

Hello,

As you know Fedora changed their package management tool a short time ago. yum command is just a redirection to dnf in default installation of Fedora and I think that we need to update running document to cover dnf command. I already made that change sent a pull request #56

Thanks for your effort and regards,

--
Akın

The site CSS is layer on top of the guide CSS, which removes the indentation. Oops. (Pointed out by @stefwalter in #88 (comment))

It should be an easy CSS fix.

The website does not mention the audience for Cockpit.

I talked with @andreasn yesterday and we initially came up with the following list:

1. Administrators not familiar with Linux (such as Windows admins)
2. People who are familiar with Linux, but not necessarily comfortable with administration tasks
3. Expert Linux admins who may not do everything in Cockpit, but want an easy way to check-in on their systems

There are two sub-tasks:

• Define audience (it might be similar to the above)
• Integrate audience phrasing into the website (likely on the front page in some form)

Steps to reproduce the problem:

• Visit https://cockpit-project.org

What should happen:

• Same content as http://cockpit-project.org

What happens instead:

• SSL certificate not accepted
• Error message in Firefox:

cockpit-project.org uses an invalid security certificate.
The certificate is only valid for the following names: *.github.com, github.com, *.github.io, github.io
Error code: SSL_ERROR_BAD_CERT_DOMAIN 

Notes:

• Visiting https://cockpit-project.github.io redirects to http://cockpit-project.org

Would be wonderful to follow the blog with my feedreader.

http://docs.getpelican.com/en/stable/settings.html#feed-settings

It looks like some update broke the style of our guides.

ToC	Sub

The color and spacing are wrong.

I did poke William Douglas over at clearlinux and he got cockpit added to the latest builds (19710+). There are still some issues, which should get solved soon.

Maybe you want to test this build and give feedback, so you can add it under supported distros on your website?
Just grab a image from the download page and do:
swupd bundle-add sysadmin-remote

My org. git request is here.

• Sizes
• Names (variety of names)
• OS (Show screenshots from Fedora, CentOS, Arch, Debian, etc.)
• System name (use obvious system names, not just Twin Peaks references)

As per discussion in cockpit-project/cockpit#2912, project page should include information related to Ubuntu.

So we won't have to build the website and commit HTML into the repo, we should port to Jekyll and make sure what we have would be able to be auto-compiled from GitHub itself (that is, not using exotic gems).

This means:

• Port to Jekyll
• Have backwards compatibility for the existing links (redirects?)

About redirects

GitHub doesn't support .htaccess redirects, but does support a Jekyll gem that provides some redirects... however the metadata needs to be in the files that are redirected to. https://help.github.com/articles/redirects-on-github-pages/

(It would be best to try to preserve existing directories and file structure where applicable.)

We could have search that is triggered on a 404 to find the right page as well.

Pagination pages listing links to blog posts probably don't matter, but actual blog posts and landing pages do.

Under the Arch section on http://cockpit-project.org/running.html it says "Coming soon..."

The reason for that while Cockpit exists for Arch, I'm not familiar enough with how Arch works to be able to write these instructions.

Any help from seasoned Arch users would be very welcome!

Cockpit's website doesn't really list features.

We should show mostly high-level features and some may link to other pages (standalone, blog post, or guide pages) with details.

There can also be certain specific features which our audience (#143) finds interesting. Examples: Two Factor Authentication, PCP integration, oVirt integration, "plugins" in the generic sense (that links to a plugins page that lists all the available add-ons) and so on.

The list of features should be on the front page. It should not list every feature, but just show the highlights that would convince an administrator to install and use Cockpit.

If you click on "Debian" on http://cockpit-project.org/running.html there is written:

sudo apt-key adv --keyserver sks-keyservers.net --recv-keys F1BAA57C

But using a short 32 bit key id is known to be easily forgable for years now.

So please change that to use at least a 64 bit key id or—even better—the complete fingerprint to fetch the key.

a bit of work, but would be great

The website has grown a lot of new content, so it's probably about time to add some high level navigation to it.

This needs to link to the blog (and back from it).
http://cockpit-project.org/blog/

We don't mention anything about regular CentOS, only CentOS Atomic.
The CentOS Atomic instructions are out of date, as I think it's shipped in a privileged container now instead (but I couldn't get that one to work).

Regular CentOS ships Cockpit 0.58

This should go on an IRC page with additional details.

…and it could perhaps also embed the Freenode IRC widget in an iframe.

The link is now active, but it still looks insensitive. It should have the same color as the other links.

Linking to the wiki

It seems the bot checked in the latest docs without adding the frontmatter header, which is a regression of #87.

This means the latest documentation is no longer indexed for searches and it does not pull in the site integration.

• Remove Android Browser 4.4+ (Google switched to using Chrome by default instead of Android Browser in Android 4 and higher)
• Add Edge (it's separate from IE, even if it started as a fork)

uses old navigation

The current screenshot is using the old navigation, and it's only one of it. Hard to get an idea how it looks.

This concerns our release notes blog.

Some users have problems waiting for

<script src="http://code.jquery.com/jquery-2.0.0.min.js"></script>

We should probably switch to a proper CDN for this.

Also

 <link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Roboto+Slab:400,700">

can fail validation.

I'm running Cockpit on my server where I run a small cluster of Docker containers. The resource usage I am seeing in Cockpit does not match the usage which Docker is reporting, nor the usage that htop is reporting.

Here's a set of screenshots of what I am seeing - https://imgur.com/a/k5km6

The only way the Cockpit numbers would make sense is if 100% = 1 full core. But that is misleading at best. If that is the case, I would consider this a bug as that is a relatively uncommon way of calculating CPU usage.

Use case - I've got a 12 core CPU, so it shows the max usage at 1200%? That is just silly.

Over on this page, you should consider adding a text like:
"Click on your distro to see the installation commands."
When a new user arrives on the page, there's no clear way to figure out HOW to install cockpit.

In fact, if you search for "installation" or "install", it is nowhere in that page UNTIL you click on the distro icon.

Another option, which I think would go even beyond, is to remove the "click-icon to reveal".
Just put a list in there:
Fedora: yum install cockpit
CentOS: etc
Debian: apt get install cockpit
Windows: format c:\
Ubuntu: apt get install cockpit

That would provide it even faster at a glance.
That's the input from someone that had never seen the page... there was no clear way of "how do I install this?!".

To index the latest guide, it needs to be processed by Jekyll, which means adding Frontmatter to the top of all the static .html pages.

This is the block that we should add:

---
layout: guide
---

The frontmatter block should be added in the bot commit process, and only to the latest guide (so the old ones aren't indexed).

As a bonus, I'm working on a simple page rewriter that will shoehorn our navigation at the top of all pages using the "guide" layout. (It also makes the guides match our website's style a bit as well.)

Here's a suggestion to start working on a redesign:

Related, for the content area: #182 (messaging improvements)

On my Fedora Atomic 27 system, sudo atomic run cockpit/ws gave me:
The image 'ws' appears to have not been installed and has an INSTALL label. You should install this image first. Re-run with --ignore to bypass this error.
And Cockpit didn't start.

Instead I had to run:
sudo atomic install docker.io/cockpit/ws
sudo atomic run docker.io/cockpit/ws

@martinpitt verified this was the case on his Fedora 26 machine as well.

The website is inaccessible over IPv6 for people like me.

In the try it out page, the Shadowman logo is used incorrectly. There are two issues:

1. Shadowman is used without the "Red Hat" wordmark. From brand.redhat.com:

Our corporate logo is Shadowman and the accompanying “Red Hat” wordmark.
We never say never, but Red Hat very seldom approves the use of the Shadowman icon alone, without the wordmark. When we do, there is always a very good reason, considered and sanctioned at the highest levels.

1. Shadowman is used to represent RHEL Atomic Host, a product of Red Hat. This is also incorrect. Again, details here: brand.redhat.com:

EDIT: I'm far from an expert in this area, which is why I don't have any helpful suggestions. You should probably contact the marketing people. Some of them might be behind this contact form.

The only way I could find that the Cockpit Blog has a feed, and what that feed URL is, was to search the closed issues on this project and find #52. Can you please make the feed more discoverable?

Guide searching works, but the way it's displayed in search results could easily be more optimal.
http://cockpit-project.org/search.html#guide

Use with:

• Arch Linux
• Fedora Server 21
• CentOS Atomic
• Fedora Atomic
• RHEL Atomic Beta via a privileged container

@stefw edited this a bit

When external pages (on GitHub) are changed, they're not automatically pulled in.

Related PRs: #149 & #150.

Right now, _scripts/update-external-docs.rb needs to be manually ran. It should be run a bot (possibly the same bot as the one that updates the guide on release).

External pages are included on the site for two big reasons:

• Cohesive experience, so browsing around is not jarring
• Search integration, so the documents can be easily found when doing a search

This is getting dropped for Cockpit itself, so best to fix here too.

Now that Fedora 22 Server is out, we should refer to that instead of Fedora 21.

I've already implemented this for Jekyll; I just need to integrate it. Simple. 😉

Cockpit is now in Red Hat Enterprise Linux 7 Extras
https://rhn.redhat.com/errata/RHEA-2015-0941.html

According to @stefwalter the Red Hat Atomic container we advice is not excellent, so he suggested just replacing that.

Atomic doesn't include Cockpit (right now), so it's better to link to Fedora 21 Server

In the Cockpit Guide at the cockpit.file session ( http://cockpit-project.org/guide/latest/cockpit-file.html ) it's mentioned that only those options are available for the file function

cockpit.file(path,
                    { syntax: syntax_object,
                      binary: boolean,
                      max_read_size: int,
                    })

As far as I could see from the sources when "file" is called the options passed to the cockpit channel just extends the options send through the file function. This means that some other options can be passed like:

host
superuser

I think, in this case "host" is not so useful but "superuser" is very useful...specially in cases where you want to save/replace a file that requires superuser access.
This took me a while to find out (since it's not in the Guide) so, I created a pull request adding this info to the guide page.

The search engine should fall back to an external search engine when JavaScript is disabled. For the sake of no-tracking, I suggest DuckDuckGo.

Example: the "Atomic" button should be highlighted on http://cockpit-project.org/running.html#atomic (as well as any other selected button)

It's jarring to have top-level navigation switch sites.

We should probably move the contribute page to the website.

It's not updated frequently (last update was in 2015), and we could basically have a simple script that fetches the raw file and appends a Frontmatter header, if we want it automated (or simply run it once in a while, when the file changes).

---
title: Contributing
base: https://github.com/cockpit-project/cockpit/wiki/
---

(I could easily extend the layout to support a base URL, so all relative links would point to the right area.)

Raw file is available @ https://raw.github.com/wiki/cockpit-project/cockpit/Contributing.md

Or, we could just copy the file as-is and make any necessary tweaks and not overengineer it. (;