True. but you missed the bit that you need to be root user.
This one will do it: sudo tail -f /var/log/syslog | grep cockpit-ws
Hi community!
Love the project and the idea behind a simplified “ready-to-go” ARM-board. So I got my pioneer editon from olimex a couple of weeks ago to play around with.
I can confirm that this problem still exists. I have not set up a proper domain yet (just running via internal IP on my home network for now to test), but as far as I can see, at least for now, Cockpit also only turns up a white screen for me after I have logged in to cockpit. Bit annoying that this is the out-of-the-box experience…
Will report back once I have set up a proper domain to report if that resolves the issue.
EDIT
PS: Running 19.22
Have you already configured TOR onion Services? I use the Tor address to log in to Cockpit
I agree. Part of the reason I purchased this was to use it as a hands on learning tool. I have tried numerous things to get Cockpit working but so far no luck.
Just installed TOR again but I am skepticall because it was installed before. As part of troubleshooting, download a new image and reinstalled. This changed nothing.
So TOR is telling me I need to have a number of Ports Open. In the past I have experimented with opening various ports because my Freedom Box is behind my router. My concern is that this is a rabbit hole that gets more and more complex for what I had hoped would be a learning tool that allows a user to ramp up their knowledge. I had a similar experience with pFsense … you had to be an expert (network engineer) to use it in certain configurations. This resulted in me dropping pSense in favour of Untangle.
I am using freedombox 19.23 on the Olimex freedombox hardware. I’m still not able to access externally, but adding https://freedombox.local to the end of the 2nd line in /etc/cockpit/cockpit.conf at least gave me access to cockpit instead of showing a blank screen. I definitely think that should be start of the standard configuration:
The current code of FreedomBox is meant to add freedombox.local (or whatever hostname.local) into cockpit.conf during initial setup as there after whenever you change the hostname. So you should not see this problem at least in new setups.
Is it possible that you have an older installation of Cockpit app? I noticed that we forgot to mark the app for automatic configuration upgrade. So, if your installation is old, then that explains the problem and we can fix it.
I am running the latest 19.23 and I get the white screen.
“You are running Debian GNU/Linux 10 (buster) and FreedomBox version 19.23. FreedomBox is up to date.”
You should see a list of domains that can be used to access Cockpit. Is the URL’s domain that you are using to access Cockpit part of this list?
Also would you please try to see if there are any errors showing up in the browser’s developer tools’ console? In the network tab, you could also check if an request is failing.
I have tried these and other variations with no success…
I bought the Freedom Box to relearn my Unix/Debian skills so I am not proficient at what you are asking. It had been my intent to use Cockpit to access the code. I do have a terminal program that provides access but I do not know how to use this code at this time.
I refer to this instruction: “ browser’s developer tools’ console? In the network tab, you could also check if an request is failing.”
19.23 add a new section to the Cockpit app that lists URLs that are currently configured. Could you check this “Access” section and list what is over there?
For developer tools, please open Firefox, then go to Menu -> Web Developer -> Network. Then reload the white page you get after launching Cockpit.
The IP address 192.168.1.37 will certainly not work. Could you check the browser network activity when you access using https://atomicboy.freedombox.rocks/_cockpit/ URL? Alternatively you can try the .onion address using the Tor browser.
It could not locate the server when using: https://atomicboy.freedombox.rocks/_cockpit/
The TOR Onion Web Browser gives a SEC_ERROR_UNKNOWN_USR:
It seems there is no fix forthcoming for the Cockpit white screen. Very disappointing.
@atomicboy after SEC_ERROR_UNKNOWN_USR you may hit Advanced... and add exception to “trust” your freedombox.
It would be great if Let’s Encrypt were set up to generate certificates with onion sites so the above situation does not happen. I understand that https with onion routing is not strictly necessary, but the error warning is potentially confusing to new users.
[See also: Manually verifying certificat for access over TOR and Let's encrypt]
I am unable to add an exception. I extracted these lines which might explain why:
"You can’t add an exception to visit this site.
The issue is most likely with the website, and there is nothing you can do to resolve it."
When I ran diagnostics in Let’s Encrypt I get:
In my newby mind … it would appear the domain name ( https://atomicboy.freedombox.rocks/_cockpit/) is not working. it substitutes the IP https://192.168.1.37/_cockpit/ which as we all know does not work.
I have port forwarding on my router setup for TCP 80 and TCP 443 as required by LetsEncrypt.
Here is a screen shot of Name Services:
