And yes, great for containers.

@Breffni-Potter said:

What you are both forgetting is that the primary target of Apple's market is no longer the studio/production house, it is exactly the home user/prosumer market that they are targeting that they will hurt the most with this.

I wasn't forgetting I was just replying to you saying this will effect studios, video production houses etc.

@PSX_Defector said:

But FreeBSD came out AFTER 4.1BSD, which is where the great schism started. Next started their work on Mach/Darwin a few years before FreeBSD came about. There is plenty borrowed from FreeBSD but it's still running kernels that are nothing like FreeBSD.

Yes, the ported the Mach kernel to the FreeBSD ecosystem. But the bulk of the code is from FreeBSD, not from Next/Mach. The OSX project started long after both FreeBSD and Next were established. That Next was older isn't really a big deal. OSX was much later. At the time, around 1999, they made a big deal that it was mostly FreeBSD with the Mach kernel swapped out for the old kernel.

Not totally unlike the Dragonfly project. Based on FreeBSD but taking the kernel in a different direction.

@JaredBusch said in Linux Lab Project: Building a Linux Jump Box:

@scottalanmiller said in Linux Lab Project: Building a Linux Jump Box:

First you would create users and SSH keys and then deploy them to the other boxes that you wish to connect to. This is the core of what makes the Jump Box a Jump Box. This is standard SSH key setup, nothing unique to a Jump Box.

Did you ever make a good write up on creating users and SSH keys? If so, I cannot find it.

I mean, I know how to make and use keys in general. But detail here would be good.

Write up for creating the users on the jump box and getting their SSH keys. Write up for pushing users and keys to other systems that said jump box will be allowing access. Write up for control of said access. Bob and Jill have access to Jump Box. Bob has Access to servers 1 & 2. Jill has access to server 2 & 3.

I know that @scottalanmiller has mentioned in another thread that he has a script to push this all out (question 2). I can only assume that the script has some controls to tell you which server so shove the key and user logon to (question 3).

I thought that screen looked familiar, lol.

Looks like a good place for me to start.. I've been searching for commands to perform tasks, and sadly search again for them since I don't remember them.

@Dashrender said:

Isn't using a SSH key and a password considered two factor authentication?

It is not generally considered to be this. An SSH Key is just a really, really long password that you probably can't remember. Would you consider having two passwords, both entered from the same place, to be two factor? I would not. It's more like one factor plus. It's an incredibly secure single factor, but the key itself is still a single factor, just a really strong one.

BASH version...

bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14) Copyright (C) 2007 Free Software Foundation, Inc.

Solus Website

Some good points. I like the one that stated keep it lean and keep it mean.

I've not gone over my Linux install as much as my Windows boxes,.. and not done nearly enough on Windows, but I generally attempt to shut down anything I am able to that isn't needed on Windows. It's not a good way to judge things, but when I see a system running 100 or more processes, I wonder what is going on.

As the site mentions: "autossh comes in handy when you want to set up reverse SSH tunnels or mount remote folders over SSH. Essentially in any situation where persistent SSH sessions are required, autossh can be useful."

Cowsay has to be the winner...

@g.jacobse said:

I rant that over in my mind, and it seemed that if the reboot failed, you would not get any type of email.

If the reboot failed to run completely (like the system was down, cron had crashed, things were frozen) you would get no email either. You are making the system report on itself with is not good.

That's why the system should reboot itself (no way around that) but the monitoring of whether it is up or not should be done externally.