Beaglebone Cloud9 Default User

I’ve been using my BBB for some time with Ubuntu 3.8.13-bone30 but upgraded to Debian 4.1.12-ti-r29 because of OS stability problems. The Cloud9 IDE is back. I opened it and saw a command shell prompt running as root@beaglebone.

Does anyone know off the top of their head where the default user is set?

I saw this, http://stackoverflow.com/questions/28822695/change-the-username-and-add-a-password-for-cloud9-in-the-beaglebone-black but after changing
.describe(“auth”, “Basic Auth username:password”)
to
.describe(“auth”, “debian:temppwd”)

and rebooting, the Cloud9 bash prompt is still “root@beaglebone:~# .”

[if this is a double post, I apologize]

I’m not very experienced with Cloud9 or BoneScript, but as I understand it, at present BoneScript is only usable for code running as root because of device driver permissions. Also BoneScript PWM is not working in the “latest” versions.

While this is not optimal, adding user permissions into the mix would likely overwhelm people coming from Arduino. Raspberry Pi currently has basically the same setup where only root users can use on board hardware, unless its changed with a new Raspbian release recently.

Are you accessing Cloud9 via the USB “gadget” or Ethernet (Wired or WiFi)? I might make a difference.

I very much appreciate the reply. I was accessing Cloud9 through eth0 not usb0 so root access from the network was possible. Were I only accessing the BeagleBone over the usb network I wouldn’t have been concerned. However I remotely connected over port 3000 and saw a command line running with root.

I tried chasing down the problem but found the Cloud9 IDE just too convoluted to figure out. I tried but failed to change the default user and password in the configuration file referred to in my earlier post. At that point I simply killed Cloud9, and just used Byobu (tmux) terminals to work with node.js.

In the latest build Debian r43 build Cloud9 is not installed by default so it’s all good. Robert’s little connmanctl tutorial post yesterday made networking much easier than messing with /etc/network/interfaces.

I very much appreciate the reply. I was accessing Cloud9 through eth0 not usb0 so root access from the network was possible. Were I only accessing the BeagleBone over the usb network I wouldn’t have been concerned. However I remotely connected over port 3000 and saw a command line running with root.

I tried chasing down the problem but found the Cloud9 IDE just too convoluted to figure out. I tried but failed to change the default user and password in the configuration file referred to in my earlier post. At that point I simply killed Cloud9, and just used Byobu (tmux) terminals to work with node.js.

You’re not alone with finding cloud9 too convoluted to even bother messing with. Personally, I have years experience with Debian( think over 20 ), and am a very experienced programmer in a few different languages. So I’m not exactly computer illiterate, and can usually solve most problems rather quickly. Not so with the current default base Debian image with cloud9 etc.

I actually found it much easier to build my own Debian images from scratch, based on Roberts kernel build guide, compiling Nodejs personally, and installing it via a package, than using the cloud9 images with bonescript, and all that fluff.

I just use a very basic custom image that is less than 200M in size, with Nodejs + Express + NPM installed, and then ssh in to write code on a NFS share <— This is so I can edit code for the BBB on a local system running Windows, in my editor of choice. VIM, and all that is kind of neat, but is not exactly my sort of “thing” . . .

I agree that if you plan to have your Beaglebone connected directly to the Internet the current default setups are woefully inadequate, I’m comfortable with my IOT stuff behind a solid firewall on a trusted subnet, but having just setup a friend with a BBG Cloud9 BoneScript and Node-Red and the USB “gadget”, it is a pretty setup to explain and demo.

Knowing better tools made me ignore it all starting with my Rev A6 BBW, but when a friend very experienced in electronics, but total newbie at programming, asked me about Arduino vs. Raspberry Pi vs. Beaglebone – he was aware of them all but unsure where to start, I had to play with the newbie stuff a bit myself before actually recommending anything.

After giving him a configured BBG (he’d have been dead in the water with the image that came in the BBG eMMC, which really breaks the ideal for a newbie idea) and showing him how to install the Windows drivers and connect to the BBG with Chrome web browser, it clearly was a great starting point for him.

After giving him a configured BBG (he’d have been dead in the water with the image that came in the BBG eMMC, which really breaks the ideal for a newbie idea) and showing him how to install the Windows drivers and connect to the BBG with Chrome web browser, it clearly was a great starting point for him.

Anything of this nature still has a learning curve. Personally, I think things of this nature are a waste of time. Not because they’re not handy, or cool. But instead you have to spend a time investment to learn anything. So you may as well learn the “underlying basics” so you’re better prepared in the future to deal with more complex problems.

So a very quick example . . . Not knowing what Node-RED really is, I’d have to spend a considerable amount of time learning this new “software technology”, when I could instead just write my own code and be done with it. Now sure, because I’m an experienced developer, who now has a decent bit of javascript / Nodejs experience, this may be easier for me. However, I had to learn all of this, just like anyone else, and in fact I’m by far not a Nodejs “expert”. And in fact, I knew very little of Nodejs 3 years ago when we got our first BBB’s . . .

What you say is true, but I’m afraid its been so long since you’ve started with zero programming knowledge that you’ve forgotten how difficult that first step is, its mind numbingly complex when you throw in all the GPIO mux options and restrictions of the Beaglebone

A GUI tool like node-red lets a rank beginner do something useful, without spending weeks learning programming and languages. Drag and drop, wire, and deploy can result it a rather sophisticated program with distributed processing – a sensor in one building communicating with a actuator in another building over a WiFi network using mqtt protocol and mosquito broker running on one of the Beaglebones – all done like drawing a schematic diagram – something people with a hardware background find “intuitive”. To use a GPIO as input or output, you drag the node to the “tab”, double click it, and fill in the necessary “properties” to make the function. The choices are limited to what is available with the “default” pin mux settings but for a beginner its feature, not a bug. If only the PWM worked, and there were UART nodes it could do most anything that needs response times on the order of human reaction times or longer.

What’s nice is that starting with node-red lets my friend ease into programming with some cut and paste of nodejs examples and modifying them in a “function” node within an otherwise working “flow” (program) to add functionality, instead of starting with a blank page and a “Programming Language Du-jour for Dummies” book in hand.

Node-red has some rough edges but it has tremendous potential for helping “subject matter experts” quickly get into programming prototype solutions to their problems. I’ve always said that its far easier to teach a Biochemist enough programming to solve a biochemistry problem than is is to teach a programmer enough biochemistry to solve a biochemistry problem. Things like node-red really lower the bar!

Go to the node-red website and look at the “your second flow” example – it “polls” the UK power grid at 5 minute intervals and reports true or false if the frequency is 50 Hz or greater (below 50 hz, maybe delay starting that induction motor a bit to let the grid recover – minimal impact from my one motor, but if millions of motors are making this decision before starting, the effect on peak load could be enormous with near zero impact to the refrigerators, etc. driven by these motors). Now list all the libraries and protocols you’d have to know about to be able do this in your favorite programming language, and tell me this is not a better starting point for an appliance manufacturing looking to make a “smart” product.

When I stumbled on to this, it just blew me away!

I “get it” though. Like for me, I know very basic electronics “OK”, but really do not have the time nor inclination to become a fully fledged E.E. Or my buddy here, who is an excellent E.E. but whom also does not want to learn how to program.

I will say that the only real differences I can think of between GPIO, and PWM in any code should only be file path, and values sent to the file handle. So anyone willing to read through,and understand the code for GPIO. Should theoretically be able to adapt that code for PWM as well.

Unfortunately, in my own case. If I do not have the time to bother learning this “something”. Obviously I do not have the time to refactor the existing code either . . .

​Several months ago I posted a note asking how to prevent the Cloud9 IDE running its shell as root. The answer pointed out where the bash command is launched.

if (options.terminal) {