Yes it's one of the reasons we moved a lot of end points to Mac M hardware and Raspberry Pis. Much lower power consumption.

Hey hey! Great project!

For a router, though, I think you want separate hardware rather than building a multi-purpose device with routing being one of the features. This is a great chance to get a low cost, low power SBC on an ARM processor that's designed for this. This won't be expensive and will be really cool and interesting and a great chance to practice running a production operating system on a different architecture.

This is something akin to a raspberry pi, except with two (or more) Ethernet ports so that you can use it for physical routing. You don't need much power, it's amazing how little routers do. So the device can be very cheap and needs hardly any RAM. Production routers over have tiny embedded CPUs and less than 1GB of RAM. So even an RP4 is massive overkill for a router under normal conditions.

Then when it is on it uses almost no power, and it is hardware that can't be bypassed.

@AdamF said in Unattended remote access utility/ computer:

@scottalanmiller said in Unattended remote access utility/ computer:

@dmacf10 said in Unattended remote access utility/ computer:

@AdamF I like the idea of a Raspberry Pi with MeshCentral as an agent for remote access.

that's what I would do, too.

Any website with IN stock Pis?

MicroCenter seems to always have them.

I really wish that I could. but the cost of flights and my limit to only 30 days a year in the country on my tax status is very hard to work with for anything but visiting family. I'm super bummed about it.

@Pete-S said in Unattended remote access utility/ computer:

I don't like the idea. It's basically a hidden backdoor into the LAN. Shadow IT.
Why not use the firewall/router instead? Every site must have one. Have it establish a tunnel to a hub of your choice.

Well the big reason to do it is security. The MeshCentral to RP way is way more secure and doesn't advertise the remote access. Few routers offer anything like that and instead push dangerous VPNs that create a lot of risk. Both are equally "Shadow IT" if you look at it that one. Just one is done well and is the recommended way, and the other is the "don't do that" way. There are good ways to do a VPN like that, but not generally using a router and it's quite safe to assume not the router that wasn't selected specifically for that purpose.

Youtube Video

Youtube Video

@Pete-S said in Unattended remote access utility/ computer:

It's more transparent and the one in control of the firewall can decide what you are able to access. I'm thinking liability and what not.

How does that really differ? In one case the IT that manages the firewall determines the access, but without security planning ahead of time (presumably.) And in the other the same IT person that can manage the remote access device can determine the remote access. Lower liability with the RP because it's more secure as an approach.

In either case, if you do it without permission, it's a problem. In both cases if you do it with permission, it is not.

@Pete-S said in Unattended remote access utility/ computer:

If you are hell bent on the idea of bypassing perimeter security, why not use something like an edgerouter? Set it up as a router on a stick and have it dial out.

That's better but, what benefit does that bring? More complexity, making them potentially change their router strategy, more effort, much much much much more difficult to keep secure. Anything that uses "use a VPN" as an option, even one that is "reach out" requires a ton of work (and trust) to ensure it is not creating extra exposure. VPNs are SO dangerous under normal conditions and usages.

The reason to do the RP method is security and good practice. All other things like following process, having permission, telling IT, etc. should be treated the same across the board. And both can have MFA and all that. And yes, in theory, you can make a VPN locked down to do nothing but allow an RDP connection to a single host and ... and ... and... if you do it all well enough, all you've done, is basically rebuilt the RP/MeshCentral solution. At no point do you gain an advantage, you only carry the risk that you won't totally recreate the solution, in the hopes of a break even.

Why NOT do the better, more secure, best practice method that's nearly zero effort right from the beginning. Why start with something complex, probably expensive, and risky only to hope you don't get anything wrong for no advantage?

Youtube Video

Youtube Video

This is an example setup from two years ago to give you an idea of what you can do with a low cost embedded SBC...

https://www.seeedstudio.com/blog/2020/02/24/how-to-build-your-own-openwrt-router-with-an-sbc/

@Carnival-Boy said in What hardware do you use for online meetings?:

I was hoping the microphone on the webcam would be decent, but it's not. I really want to ditch the headset and use a microphone so I feel less constricted and uncomfortable, but I'm not sure how good cheap microphones are (circa $50).

I use an Amazon Basics desktop USB mic. Sits on the desk on a tripod, sounds pretty good, points at your mouth. Still pretty close. It's cheap but does a great job.

@AdamF said in Mesh Central:

if I don't want to put this behind any proxy

That doesn't do much anyway. There's really very little to do. It's a web page, so basically think of it link a bank website.

@AdamF said in Mesh Central:

@scottalanmiller I am missing the 2FA option in the my account settings. I am missing something I suppose?

Because the name is dumb?

My Account >> Manage Authenticator App

@Pete-S said in Save shell session to disk?:

The problem is that I want to save the unix shell session on the server. Screen buffers, environment variables, history, current directory etc. So I can resume my work later from the same point.

So there are two ways to do this...

1. Work in an idempotent way and be stateless. Basically doing functional programming. Huge pain and no one does this. But this is how this would be handled.

2. Live without the ability to survive a SERVER side reboot, and just use screen and it is designed to do this (except for the reboot thing.) You disconnect your session and can pick it back up in situ from anywhere.

@AdamF said in Mesh Central:

@scottalanmiller said in Mesh Central:

@AdamF said in Mesh Central:

Well, this tool is amazing and just works. Nice job @Ylian !

Yeah, it's definitely the best tool for this on the market. It's blown past everyone else. We are doing the AMT integration now and rolling out vPro anywhere that we can. It's just amazing.

I know you use it for remote agents that are always installed (or at least I assume so), but are you also able to use it for "one off" remote sessions? For example, sometimes I will open a screen connect session for a quick support session. Then when finished, close the session, the end. Can we do that as well with MC?

Yes, works fine for that. The end user just chooses "Run" instead of "install" and it works that way.

@siringo said in New server q's:

My main question is what RAID level are people using these days & if I chose a server with spinning disks, would I look like an idiot who didn't know anything?

RAID is dependent on many factors. It's not chosen in a vacuum but in conjunction with the choice of type, controller, and disks. You don't lead with RAID, all of those choices are a singular whole

And yes, in general, choosing spinning disks for a small system would be pretty crazy.

@siringo said in New server q's:

As an example of what I mean, the server had 32GB of RAM and I got that from 2 x 8GB and 1 x 16GB. From memory the advice was I should have used 4 x 8GB sticks.
Can anyone confirm that for me??

You generally want matching sticks and often they work in pairs or tuples. But, like the RAID, memory cannot be planned in a vacuum. You have to know your processor, motherboard and RAM options together. It's a singular choice.

@siringo said in New server q's:

Software RAID. Gee I'm outa touch, that used to be frowned upon.

It was "frowned upon" only as a myth in the Windows world. This came from the RAID in Windows being total crap and uselessly buggy. So many Windows Admins, not knowing RAID or systems administration or the broader world of computing, misassociated the problem with the concept rather than the implementation and started a myth that Windows Admins repeated to the point that no one ever questioned or evaluated the logic. Logically, how could software RAID be bad since hardware RAID uses software RAID? IF software RAID was bad, why did every enterprise storage system and server use it, always? All the big SAN systems that the same admins depended on almost universally use(d) software RAID. So in one breath people said it was bad, and also said it was the only thing they would use.

Youtube Video

The issue was exacerbated by the FakeRAID market that preyed on Windows Admins as well. Since storage and computing concepts were so poorly taught in the Windows world, the entire market for third party software products that gave a high level impression of happening on hardware (but are easily detectable as not) arose to trick admins into paying a lot for something that wasn't really a thing. So in the WIndows world, FakeRAID also make admins who couldn't identify what they had blame software RAID instead of their own confusion.

Youtube Video

@Pete-S said in SSH jump server access control?:

Or is there a possibility to limit network access depending on the user account as well? If that is the case, how is that done?

I bet you can, but we don't. So I'm not sure how. Generally you assume that access "to" the jump box means it is a trusted person already, then the additional access to the next device is limited to user access rather than network access. It's not that you trust them completely, but you don't limit their ability to launch a DoS attack or something at a network level.

@Pete-S said in SSH jump server access control?:

When we use VPN for remote access, each user is assigned his own unique IP address. Network access is then controlled by network firewall rules.

So this is application level. Meaning, the port is open everywhere, access is blocked AFTER the connection. Which is how it would have to work, so that's fine. Anyone can attack your VPN, but access after getting into the VPN is limited by IP. So that's different than limiting at the SSH layer, it would be within the SSH transaction.