Dropbear ssh server on nerves device

ssh
nerves
buildroot
raspberrypi
debug

#1

Hello!

I’m step by step getting deeper into nerves. I think it’s awesome. I’m reading and watching lots of resources related to buildroot, busybox, and nerves, but I still have many questions.

I’m using a custom raspberry pi 3 firmware. The only two changes I want to make is install dropbear and postgresql. My question now is about dropbear.

After reading this, I’ve added the package using make menuconfig, saved the configuration, and compiled. I’ve also added a file under rootfs_overlay/etc/default/dropbear with the following content:

DROPBEAR_ARGS="-p 222"

I’m using an USB serial converter for the rpi3 and I’m using also nerves_init_gadget so I have access to the IEx console via ssh in the default port 22, that’s why I want to run dropbear on port 222.

I can’t make it work. It looks like dropbear is not even starting. I can get into the system from the elixir shell, but is tedious:

System.cmd("dmesg", [], stderr_to_stdout: true, into: IO.stream(:stdio, :line))

I see nothing related to dropbear -nor postgresql-.

It looks like dropbear and postgresql use systemd for starting services, is it configured on the rpi3 nerves base system? I couldn’t find information about that.

Thanks a lot!

Adrián


#2

You will have to start dropbear yourself manually. A while back i built a dropbear wrapper. Check it out here


#3

Thanks @ConnorRigby! I just realized systemd is selected by default, and cannot be selected because I get this error:

... is not using a merged /usr for the following directories: /lib /bin /sbin.

I was investigating about using busybox for the init system but your solutin on elixir looks better


#4

You will almost always want to use Elixir for init. There is no other init system installed. /bin/init is replaced with a small program that only starts the beam vm. so no /etc/init.d, systemd etc. Enabling those things will break a lot of things.


#5

Thanks, that is a very useful information. I think it should go into the documentation or the FAQs, because often you would need some kind of service running probably.


#6

Thanks for the feedback! I agree that we should have some documentation about how the Nerves “init system” works (i.e. there isn’t one and you just use Elixir process supervision with Ports).

When you were looking in the docs for how to do it, do you remember where you looked first or where it might fit? Or did you just assume that systemd would be there and it wasn’t? The FAQ is the lazy/obvious place to put it, but curious if you have other thoughts because I don’t like having a random grab-bag of things there if there’s a more helpful place for it.


#7

@GregMefford thanks for your interest!

I think the first place I looked was the Systems page. I think is a better place to add the init information than the FAQ.

When I started to work with nerves, the documentation didn’t provide all the information I needed. I come from the web world, and even though I have knowledge on systems, I didn’t know a lot about buildroot, busybox, and so on. I had to find information about that.

For me it would had been very helpful a reference page informing how nerves has been built, and what is and what is not. Also some information about the tools nerves is based on, and the initial system you get with nerves. I found this reply from @ConnorRigby useful.

Usually, people come to nerves because they have a project in mind, and the project involves several stages, like setup, customization, setting up other packages, communicating using IO ports, sensors, UI interfaces… I’m not saying that we have to include all the stages in the documentation, but at least a section like “Where to go from here” or “What you can do now” that points to other documentation for those tasks. This will be useful for a newcomer that has a project in mind and doesn’t know exactly what it’s needed for getting it working.

I’ve been impressed with the community in this forum, providing quick and really helpful replies. If it wasn’t for this forum I probably had abandoned nerves. Also, the library Nerves init gadget was very helpful, and without it I probably had also abandoned. I know that it was designed for the Raspberry Pi Zero, and I’m using Raspberry Pi 3 but I need it, because it has some useful tools that I couldn’t have created myself, and I use a lot, specially mDNS, OTA firmware updates and RingLogger.

Said this, after every step I made through making my project work, I was impressed about nerves. I’m really thankful to the community and the developers that made this possible. Elixir (with OTP) and embedded devices is a perfect match made possible by this great project.

If I can contribute to this project I’d be happy to. I really like it. I don’t have experience yet and I almost have no free time on my life :slight_smile: but I would try to spend some time on it if there are some small and easy tasks I could do.

By the way, there are some open source projects based on Nerves that impressed me a lot, and got me excited about the possibilities of creating a better world. I’m talking about Farmbot, but I’m sure there are many other great projects over there too.

Thank you all the core developers, for creating this and being so helpful.


#8

Thanks again, this is all super helpful insight! :heart:

I assume that the first thing you found was the Getting Started guide , which ends at the point where you’re directed to some simple examples. Are you thinking that the end of this guide should have another “what’s next” section, that points you to some deeper information about Nerves concepts like Systems, adding packages, how to structure your application, etc.?


#9

I’m glad it helps :slight_smile:

yes, what I found first was the Getting Started guide. IMHO it would be helpful another section at the end that points the user to deeper information, because I think more often than not, devs would need to use these concepts in their projects.

The examples are great, but including tutorials explaining those examples (in the docs, a wiki or any other place) would help too.

There are some things that would be used by most of the projects, like networking and debugging, that would be nice to have in the documentation too. Or at least a link to external documentation. Using a Raspberry pi example with a USB to serial converter and minicom or picocom is some of the most useful information I found for working on the project.

Let me know if I can help :wink: