configure_edison (oobe) not working out of the box about meta-intel-edison

[htot]

I am 90% rewriting this using bottle to eliminate the dependency on node and to start supporting connman's tethering functionality.

[mwallnoefer]

I have done a quick check on configure_edison which revealed that it uses hostapd and the standard version of wpa_supplicant, which differs from the one bundled together with connmanctl.

So all wpa_cli calls fail since they are not able to locate the socket.

[htot]

Like I said, I am completely rewriting this. Hostapd has already been eliminated. If you like I can push that branch so you can work on that to speed it up a bit. Python is not really my thing.

[mwallnoefer]

Yeah, if you have something working I gladly review it.

[htot]

It's a web server, things are half working. I think you can rename the edison network name.

Originally there was a python cli and a node web server. Now the node code is dropped and python provides both cli and web server.

[htot]

Oh it displays stuff (connections), but doesn't let you change it yet.

[htot]

It's here https://github.com/edison-fw/edison-oobe/tree/rewrite-wip
To make it work meta-intel-edison needs 2 patches see https://github.com/htot/meta-intel-edison/tree/oobe
As you can see this is wip, so refers to locally checked out edison-oobe/master.

[mwallnoefer]

Okay, the first thing which I notice is that the Edison wifi is still not available per default. So first I need to go into the serial console to enable it.

connmanctl
enable wifi
tether wifi on <ssid> <passphrase>

[htot]

Yes, this should be taken care of by post-install.sh. Does this fail for you?

[mwallnoefer]

One thing which we need to discuss is the handling of SSH. In original Edison it hadn't been enabled until a root password was set through configure_edison. I see it less a problem within the Wifi AP mode (where we have a password protection), but when we are in normal client mode it constitutes a security hole.

My proposals:

• Restore the old behaviour on behalf of configure_edison. We could disable it at the systemd level and let the script/web interface enable it afterwards (otherwise the user does it manually by running systemctl enable ssh).
• Set a default root password (= serial number)

That's the current code in configure_edison:
sed -i 's/^BindToDevice=/# BindToDevice=/g' /lib/systemd/system/sshd.socket ; sync ; systemctl daemon-reload; systemctl restart sshd.socket

[htot]

Yeah, I think that is some 'tweak' thing that we have enabled in the image.
Don't forget, configure_edison is not necessarily run, postinstall is. As is now, you should be able to start configure by pressing on of the buttons, which should allow wifi ap, or bluetooth tether and start the web server.

If you ask me:

• the root home dir should be under /root and not /home/root.
  As is a failing mount on /home will prevent root from logging in
• root should only be allowed to login via the console, not any other serial (bluetooth/usb) or ssh
• I like your idea to make the root password equal to the serial number
• we should create a user (admin?), with home dir /home/admin, with ssh and other tty login rights
• what should be the password? admin (lol)? or the serial number again?

[mwallnoefer]

If you ask me:

• the root home dir should be under /root and not /home/root.
  As is a failing mount on /home will prevent root from logging in

I guess that this choice was taken since here we are working on an IoT device, were permissions do not play such an important role as on a desktop or server. People should be able to use the HW with as less caveats as possible, including all port numbers, serial lines and GPIO. Hence the decision to access with the root account.
Since the homedir is the default place where to leave arduino sketches and other programming work, it has been chosen to move it under /home to not overwrite it on a re-flash.

But does a failing home mount point really impede the user to log-in? Does it not just raise an error message?

• root should only be allowed to login via the console, not any other serial (bluetooth/usb) or ssh

Console...you intend the serial console (ttyUSB), correct? For me, a password-free root access is only acceptable over that medium (since you need to sit beside). All other access methods should be protected, I agree.

• I like your idea to make the root password equal to the serial number

Agreed

• we should create a user (admin?), with home dir /home/admin, with ssh and other tty login rights
• what should be the password? admin (lol)? or the serial number again?

As I understand you would like to add some sudo-style super user account. While this is fine for experts, I fear to loose the non-expert - medium user as I have explained in the paragraph above. Moreover we completely break compatibility with the other maker boards and can forget about reintroducing some degree of Arduino compatibility 🤔.
Hence I am a bit reluctant with that decision...

[htot]

But does a failing home mount point really impede the user to log-in? Does it not just raise an error message?

Yes. The mount is done by systemd and keeps retrying. I had this while experimenting with btrfs and forgot to create the @home subvolume. Fortunately I had already created the rescue initrd.

[mwallnoefer]

If someone else is reading this, I have fixed the cmdline configure_edison tool and partially also the web interface (at least the hostname, wifi and ap part).

Please find the updated code here: https://github.com/edison-fw/edison-oobe/tree/rewrite-wip

[mwallnoefer]

Please find here the inclusion patch for the rewrite-wip branch which drops the whole nodejs stuff: oobe-rewrite-wip.diff.txt.

So that it doesn't get lost...

[htot]

Thanks. I just noticed a few days ago that it's still pulling nodejs. I applied with you as author.

[htot]

I would say that with your recent patches we can say that oobe is now indeed working out-of-the-box. Thanks!