Hi,
I am posting this as i believe it should be covered and i was unable to find any ultimately useful information from a novices perspective.
First off, thanks this is awesome im blown away so thanks.
The Problem:
-New user installs and wants to download and trust root CA to commence journey
The guide tells user to enter commands in a terminal, user searches and finds start9 does not have a terminal nor can tty`s be accessed. Start9 | Trusting Your Root CA on Linux
-So user goes to the next menu entry which counter intuitively is SSH keys for ssh access, and the documentation advises that in order to generate a key they must open a terminal⌠Start9 | Using SSH
I love and share the founders vision and i am blown away by the execution, and so while i am sure many of us including myself have sufficient tech skills that enough bashing around i will eventually solve this. Having some clear instructions here would be great and i dont feel i am sufficiently knowledgable to provide a clear concise solution, so do i have any takers? once a clear solution is made it is my hope to edit the post removing all the discussion elements so a simple Question Answer format is created under a suitably named and searchable forum topic.
The way i solved the problem was to follow this guide Start9 | Using SSH on another system
Perhaps that is what is what is intended by the guide, and if so does any one know how i can propose amending the documentation to make this clearer?
step 1 of âCreating a SSH Keyâ currently reads âOpen a terminal and enter the following command:â
For clarity it should read "Open a terminal (on a separate system) and enter the following command:
Hi ExoNos⌠I was about to thank you for the clarity and detail of your original question, but then disappoint you in still being a little confused by what youâre asking.
You see, the only way you could work out that your server doesnât provide access to any kind of terminal/command line interface is if you are using it incorrectly. You should not be sitting in front of the server with a keyboard, monitor and mouse plugged into it. Itâs a server, not a client device. Everything thatâs in those guides should be performed on your regular client device, with your server off happily sitting headless alongside your router somewhere.
At no point should you be interacting directly with the server for these guides. Whether it is trusting the CA or setting up SSH, these guides are for configuring the regular client device(s) you use to be able to access your server as a client.
Hi Stu,
Thanks for your response, and you are absolutely right (in a way haha)
While i was in fact on my laptop, logged into the server via https, my perspective was that i was on the server, (the documentation is linked via the server user interface) so i interpreted the information in the context of being âon the serverâ as opposed to being âon the laptopâ.
While i understand and can see, (now that i know) that all the documentation is written from the perspective of being physically on a separate device, as a new user reading the documentation this was not clear.
I originally was confused by what appeared to be an unsolvable loop, (other than physical access, boot disk, manually editing) once i realized the documentation was intended to be run on another system, i thought that proposing an amendment to make this clear would be useful in:
A. keeping with the projects stated goals
B. Assisting future users that also had the incorrect perspective when reading the documentation.
Thanks for this detailed and thoughtful explanation, I better understand where youâre coming from. Iâll take it into account as we work on the latest version of the docs.
I agree with you that for people who are not familiar with working with headless servers it would really help to clarify for the ignorant that all the steps you perform from doing the Root Certificate to getting SSH setup is all done on the client machine. I myself (out of ignorance kept trying to get a terminal window open sitting at the server.
I canât agree strongly enough with this request. The first line of every instruction should begin with, âFrom the client machineâŚâ. A little paragraph at the beginning explaining what a server is and isnât, akin to Stuâs admonishment above, would also go a long way.
Iâm muddling through, but all the current instructions that start with âOpen a terminalâ stop me dead in my tracks.
Thereâs no starting point where a monitor is connected. Everything begins with âon a client deviceâ OR typing in start.local into a web browser (which youâd not be able to do if youâre on the server itself)
We could change the first part of every page of the guide to âon a client deviceâ but it would be a little redundant as the guide starts off with you on a client device and none of the steps work on anything but a client device.
I have tweaked the language on the next version of the docs though. Howâs thisâŚ
Thanks for responding, Stu. The new copy seems more helpful. The true test will be whether it can overcome the next batch of newbies with that powerful nagging feeling that theyâre supposed to be doing something on the server (especially if itâs an old laptop with a keyboard and active screen right there). Any attempts to smack us upside the head before we make a mess are appreciated.
Yes, i also appreciate that you have even looked at this let alone tried to address it in spite of, as you have pointed out, the existing documentation already preconditioning the user.
I cant speak to the others, however my confusion never stemmed from being on the server physically, it stemmed from what for me is still a persistent mindset, and that is that whenever i am logged into a server regardless of my proximity to that server or how i access it, i perceive my self to be on the server.
Therefore when im on the server setting it up using documentation which i have been prompted to use by links on that server, if the documentation says open a terminal the intuitive thing for me at that moment is to think it refers to opening a terminal on the server, not the client device i am using to access it.
Clearly had i obtained the documentation prior to the install and read those specific instructions i would have had the context which you have rightly pointed out exists.
I suspect a lot does have to do with not being accustomed to setting up headless servers, which potentially many of the users also will not be.
@StuPleb I often had issues connecting to my server. The reason for the latter is start.local doesnât work well with every browser. A work-around is using the IP adress of the server which is not too difficult to find from the wifi setings or an app like Fing. Regarding the browsers, Brave has all sorts of loops to stop you from connecting to local hosts and they are really time consuming to navigate. I use Firefox now and have no issues. Iâm sure others have struggled with that at the beginning like I have.
I think Brave isnât so much blocking access to the local network but blocking access to certain scripts and so loading a white screen⌠something you can also see on Firefox if you crank up the security settings. But if you say thereâs a particular means of making it not load start.local but correctly load the IP address, I believe you.
The whole reason start.local exists is because a large number of people have no idea what an IP address is or how to find their server IP address. Thatâs a tough problem to solve.
