Products > Embedded Computing

Running a web server on an embedded system - risky?

<< < (5/7) > >>

DiTBho:

--- Quote from: Nominal Animal on November 12, 2021, 03:46:20 pm ---you can run Linux on pretty scanty resources: 4 to 8 MiB of ROM/Flash, and 32 MiB or more RAM

--- End quote ---

my personal experience with PPC and MIPS32 routers

kernel+uclibc-roots in 8 MByte of ROM/Flash:
with kernel 2.4: yes
with kernel 2.6.x: { x<26 -> yes, x>25 -> maybe }
with kernel 5.x: no

SiliconWizard:

--- Quote from: peter-h on November 12, 2021, 06:48:16 pm ---A great feature idea - many thanks :)

"they themselves push and pull data to/from outside servers, but they do not act as servers themselves."

That isn't futureproof; as soon as the vendor stops running that server (which is certain to happen), you lose some part of the functionality.

--- End quote ---

Of course. And I don't like this IoT cloud stuff all that much anyway. But it's the only reasonably scalable solution at the moment, and it provides some safety net. A single, low power device acting as a server, yeah. Not only would it be kind of hard to secure correctly as we evoked, but it's hardly going to be scalable. Another related issue is that accessing it requires an address that may have no domain name attached and maybe even no fixed IPs. If you're targetting uses in a professional context, that's probably not a problem, but for individuals in their homes? Most private internet accesses still don't have a fixed IP. Something that can sort of be mitigated with services such as "dyndns", but that's a burden and end-users wouldn't want to mess with this.

An ad-hoc solution may not be all that much more future-proof either. Maybe at least you should consider for it to support IPv6, because IPv4 only at this point is not going to be future-proof.

First thing IMO would really be to ask yourself if this kind of remote access is a real benefit. What kind of devices are you thinking about?

ralphrmartin:

--- Quote from: peter-h on November 12, 2021, 08:59:43 pm ---What is the lifetime for Let's Encrypt certificates? For how long are they valid? ... Our certificates are valid for 90 days.

So now you need a process running every 89 days to renew this certificate, and this is quite likely to break, sooner or later. It is the fashionable modern way to do this but it also breaks easily. Just had that at work.

--- End quote ---

I use certbot for automatic certificate renewal, run in a cron job, and it has never failed for me.

peter-h:
"First thing IMO would really be to ask yourself if this kind of remote access is a real benefit. What kind of devices are you thinking about?"

I don't think the product I am working on will likely be on an open port, but it is a possibility. If it was done, the customer would need to understand firewalls etc.

" The S you probably want to outsource to make sure it's correct, but essentially it's just a shim under HTTP and between the comms media, isn't it? Doesn't mean you need a pukka 'server' to do it."

Someone else is doing that part, using MbedTLS. The STM library was as usual buggy and lots of people have struggled to fix it. It also consumes 50-60k of RAM; a bit less if you are a client not a server.

DiTBho:
Someone or something (An alien on the roof sucking my wifi? A Loa of voodoo? A free running string of AI on the internet? who knows ... ) is knocking on port 22 (Ssh) of the automatic greenhouse for growing tomatoes in hydroponics :o

Daily quirks have been happening for a while, it seems like someone or something really wants my tomatoes.

It's an embedded Linux board based on TL-W703 exposed to the internet and when fail2ban bans its IP, somethings changes the IP, waits 661-669 seconds and tries again.

port23 ... umm, running a ssh-server on an embedded system is very risky ... it wasn't a brilliant idea, I think  :-//

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version