Cockpit server administration

I have a Pioneer plugged into my router, Three other computers are all on the same network. I’m using Debian GNU/Linux 10 (buster) and FreedomBox version 19.2. FreedomBox is up to date.

When I log into cockpit, it accepts my user name and password but all I get is a blank white page. Any suggestions?
theboxcoach.

If you are asking for support for an issue, please include the following information at the top of your post:

  • Whether your FreedomBox is plugged into a router at home or not (if not, please specify how it is connected to the internet)
  • The month and year you bought your kit (feel free to omit if you want to preserve some privacy, but this could be helpful information)
  • The version of FreedomBox your are running (available by clicking on the “?” in the top menu --> “About”)

There’s an issue with Cockpit where it shows a blank page on first login but start working after refreshing the page in your browser.

Another known issue (reported by @simjim) is that it doesn’t work when accessed using the IP address but works if accessed using the domain name (like a DynDNS domain name or Tor hidden URLs).

i agree, issue still not solved.
cockpit works when i log in with tor
cockpit is blank when i log in from my home network
the refresh trick does not work with me

I’ve got TOR working. Can browse the internet but can’t connect to freedombox.

I’m having the same problem here, I logged into it once from a remote location, using pagekite, but it has not worked since. All of my letsencrypt certs are working just fine, so I’m at a loss as to what might be the cause.

Cockpit requires a proper domain to be configured and that you access using that domain name. This was discussed elsewhere but was lost. I have updated the manual page with this information. Could you please try that and see if it fixes your problem?

Hi all!

I work on the Cockpit project and would like to see this fixed too. :wink:

What browsers are you using where you get blank pages? The only browser I’m aware of where this consistently happens is on Safari on iOS (as there’s an issue with self-signed certificates on iOS specifically). Related bug: https://github.com/cockpit-project/cockpit/issues/11844

Setting up your FreedomBox on its own domain as @sunil suggests should even make that Safari work too.

There are a few configurations can trigger this issue in other browsers too, however. In a quick search, I found:

https://github.com/cockpit-project/cockpit/issues/8703 — but I think this might’ve been fixed a year ago (at least in some cases).

1 Like

Continued (as there’s a limit to 2 links for new users):

The fix could have been @ https://github.com/cockpit-project/cockpit/issues/9543. If your version of Cockpit happens to be quite old, it’s worth upgrading.

If the above issues are not quite right for your case, please file issues @ https://github.com/cockpit-project/cockpit/issues/new?template=bug_report.md and be sure to share which browser(s) and the version of Cockpit you’re using.

You can find out Cockpit’s version by clicking on your name in the top right, and then selecting “About Cockpit”. The version is a 3-digit number.

Thanks! Hopefully we can get it fixed (as long as it’s not a misconfiguration issue).

1 Like

@garrett, thank you for taking interest in getting Cockpit working properly for FreedomBox. It is always thrilling to see upstream interest in FreedomBox :slight_smile: In the upcoming release, we are making Cockpit an essential component of FreedomBox which means Cockpit will be installed and enabled by default.

  1. I have found a problem with FreedomBox’s handling of domain names for Cockpit. It was not restarting the service properly after modifying the cockpit configuration file for the Origins directive when a new domain is added to the system. This would mean that for people who change their domain name and didn’t restart their machine would not have Cockpit working properly. This will be fixed in FreedomBox 19.15 which will be available in a couple of weeks. https://salsa.debian.org/freedombox-team/plinth/merge_requests/1538

  2. Another issue is that users who setup FreedomBox will typically be using freedombox.local as their domain name. This was earlier not being configured as a valid Origin for Cockpit. The proposed changes also fix this by allowing .local domain part of Origins.

  3. Showing an error message instead of blank page will go a long way in helping users identify the problem. https://github.com/cockpit-project/cockpit/issues/11844 helps greatly in this aspect but can be better. Instead of showing a generic message, Cockpit is in a position to show that WebSocket connection was not possible due to misconfigured Origins. A message such as ‘Cockpit is not configured for use on this domain’ would be more appropriate. I will comment about this on that bug.

  4. Since FreedomBox configure Cockpit on a web path instead of a subdomain, could you confirm that the following Apache configuration we are using it okay (Cockpit is accessed as https://freedombox/_cockpit)?

    <Location /_cockpit/>
        ProxyPass http://localhost:9090/_cockpit/
    </Location>
    
    <Location /_cockpit/cockpit/socket>
        ProxyPass ws://localhost:9090/_cockpit/socket
    </Location>
    
2 Likes