 So I figured it would be a good idea to talk a little bit about why I switched the server I have from, it was running Arch Linux, so a Linux distribution tailored around being very true to GNU Linux, very minimal changes to Windows Server. That's a side of things you don't normally hear about. It's overwhelmingly Windows users who've switched to Linux talking about why you should switch to Linux and not Linux users switching to Windows about why you should switch to Windows. Both happen. Both systems have their merits, just as other systems do, and I will bring those up in this as well. One of the most startling reasons, and I'm not sure what the cause of this was in trying to diagnose it, I even utilized a few other Linux systems and a few other Unix systems with mixed results. You can see here I very clearly have 32 gigabytes of RAM installed in this machine, and under Linux, whether it was Arch or something else, I've tried this with Ubuntu, with Soos, with Fedora, plenty of others, a lot of being nine total systems, I tried this on with varying kernel versions and everything else, would randomly at boot either recognize 16 or 32. It seemed about four out of five times it would recognize 16 gigabytes and not the full 32 that are installed. At first, I thought this was an issue with the memory, ran it through numerous mem tests, and constantly reported back fine. Now, I can definitely say it's fine because, oh geez, must have been about 20 reboots on this system for various reasons and 32 gigabytes every single time. But after trying quite a few of the Linux systems, what I did before deciding on Windows Server was try out FreeBSD, NetBSD, and OpenIndiana. FreeBSD and NetBSD are very obviously BSDs, hence the name. Dragonfly is really the only oddball there, both of which are pretty true Unixes, Unix certified systems, but very true to the origins of Unix, excellently designed systems. I don't agree with all of the design decisions, but you can, any system, I don't agree with all of the design decisions. That ultimately wasn't a viable option for me because of some hardware and compatibility issues, and yes, even if that was a server, just hardware compatibility issues. So, I mean, we're talking like one of the SATA controllers wasn't recognized, which is a pretty rough problem. I need both of them being recognized. But also, just other things, just other hardware and compatibility issues. Getting an IDA compiler set up on the BSD is a little bit trickier, but it's not that bad. You have to bootstrap the compiler, but honestly, the ports or package source collections are both excellent and do a fine job at bootstrapping. It's just a little bit of a long process, but it's not bad by any means. It's a lot better than trying to bootstrap it manually. If you've ever installed NAT on a Gen2 system, you've seen what that's like. It's very straightforward. It just takes a while. Then OpenIndiana, that is essentially derived from OpenSolaris. You're seeing Solaris and OpenIndiana diverge slightly. I decided OpenIndiana would be better just because NAT is based on GCC and OpenIndiana has been modified to work more around GCC rather than the old Sun compilers. Very minor thing at this point. In most situations, the two can be used pretty interchangeably. Hardware issues again. I knew this going in. I just did it for like, hey, let's see. No add a compiler. You can do it if you build it manually, but that kind of stuff is a nightmare to do. If I remember right, the Idox project had build scripts available for that kind of stuff. We're talking a long time ago though, because I had contributed to that project years ago and before I realized it was doomed to failure, but I swear I remember having build scripts. I just don't remember where they were. Then I got to thinking, do I really want to be running this test code in the libraries that I'm developing and everything on the server proper? Even if it's my own code and I generally know what I'm doing, that's still a vulnerability. It's always possible you write code that goes haywire and obliterates your hard drive or something. It's rare. Extremely rare, but it's just still good practice to not do that. Hypervisor. It's not like Linux or Solaris or the BSDs don't have hypervisors. In fact, Solaris especially has remarkably excellent hypervisor stuff available for it. Not to mention a lot of the time you don't need it because the BSD and Solaris have very wonderful concept of zones and jails. Not at all like the Linux containers which are kind of hack job attempt at zones and jails. Neat way they implemented it though. Containers have some neat properties, but they don't hold up to the well designed zones and jails. But the management tools for Hyper-V, I've got to say, are definitely one of the best. And I've known that for years now because this is Windows 2012, our two license. So we're talking 2014. I bought this. This goes back a while. I can't show it on this, on like my actual workstation I'm recording this on because I don't have a domain joined up and I don't want to dink around with all the other things to get this to work. But having an actual interface for managing the hypervisors is actually quite lovely because I can just simply start that up. It's very easy to work with these kinds of things in this way. Good command line tools make it still highly possible, but it's very efficient to do this. But more importantly, if I were in like a domain joined situation, I can load up Hyper-V manager on this workstation and have it connect because this is fundamentally a MMC, Microsoft Management Console. It can bring up the other servers that are running Hyper-V all down this list view. And I can just manage them all from one central console. Similarly, you can say like if I had that actually set up, I could bring up Hyper-V on this workstation, have it list all the stuff on the server, and then connect to one of the ones on the server. And even if the operating system underneath it doesn't support RDP or VNC or any of that remote display stuff, I can still have it show up on this computer. Eventually, I will get to that point. I'm still sort of slowly configuring things because I've got other stuff also going on. So having the ability to do that is considerably, considerably easier for managing stuff than any solution I've seen with say Zen for Linux or the various hypervisors that exist for other systems. That being said, they're starting to play catch up with the centralized management console. As I understand it, GNOME boxes is implementing a lot of this stuff. So that's good to see. But it's not just limited to Hyper-V by any means. Now I use this for my test lab. I've only got two VMs set back up, but eventually this will be a pretty long list that I'll actually need to scroll through regularly because this is basically a test lab for the code I developed to make sure that it runs on a variety of platforms and interacts with the base systems nicely. But this is not all that I use. One other incredibly important thing, and I've dinked around with this with the NF Tables and what's the... NF Tables is the new one for Linux, but there's... if you look up firewall guides, like what shorewall works with, but also just look up anything about the Linux firewall, it's about a slightly older firewall slash routing subsystem that exists within Linux. I'm not a Linux expert by any means. I'm quite comfortable administrating one, but I'm not too familiar with the internals and everything. But... Oh, I'll show this first. It's very closely related. Actually, no, go back. This machine is set up as a gateway. Quite obviously. Basically a router, too. There's one Ethernet port that's connected directly into the modem, so the WAN. And there's eight Ethernet ports because I have two network cards each with four ports. I see six of these are being used. The other two are not currently. At least one of them is going to be used for another ARM development board probably just by a Raspberry Pi. Use that. Because basically just extending the test lab just to also work with ARM hardware. And then another one, probably the MIPS. We'll see. Trying to secure something for like a power PC or something, but that one's looking difficult. So it'll probably be a MIPS. But then all of these are bridged together as the single LAN. So that they all share the same IP address and work just like a router would. But a router's done with a switch, not eight individual ports. So obviously in that kind of situation, being able to manage the firewall is incredibly important. And I just, I had such a hard time managing the firewall under Linux. Even if it was using so-called high-level tools like shorewall, which are supposed to make it really easy, just the firewall manager in Windows is so much more pleasant to do in my opinion. Maybe it's just how we work with things, but I find it a lot easier to do. So for example, one thing you really don't want to do is have remote desktop stuff, which I obviously have enabled, access to the greater public. So I can do very easily things like selecting the different remote desktop stuff. And as you can tell that that one's not even out to the public. And in fact, it probably none of these are. Right. Okay. So none of them are, which is a very sane default. WINS is a good example. Something like that does not need to be exposed to the public because it's literally useless to the public. Plus, I don't want to be issuing names for things in the public space if they happen to... Oh my God, just thinking about that is sort of horrifying. But if something were to actually be broadcasting that stuff on the greater internet, that would introduce so much congestion. Oh, I already adjusted that one. And so just like that, I have the entire WINS stuff blocked on the public, at least for inbound rules. I don't for outbound rules, but one... This is another one that should definitely be... What was I just saying? No, I forget. Well, anyways, something that I really like about the approach they take here is that it's possible to define stuff, say at the protocol level, like I've done this for the stuff that bit-shoot mining uses. Where is it? As you can see, I have specific ports defined. But for plenty of other things, say... When does media player is a good example? Where is that one? No, I have these completely off. But you can see that if we go here, there isn't actually anything labeled for the ports. Rather, it's the specific program. This makes it very easy to do fine-grained firewalls, in my opinion. Because you can get to levels of saying like, hey, let's open port 80, but also only for this specific program. That's really nice. Now, by default, if I were to go through all of these that are open, or active, rather, you can see that way too many of them are open on the public interface. And really should not be. I guess it's a reasonable default for usability purposes, but definitely not a reasonable default for security purposes. And unfortunately, you got to weigh the two. But I do really like the option of more program focused than packet focused firewall control. And I just find this so much easier to work with. So much so. Another really nice thing, of course, and I don't really mind showing this off because it's a public network anyways. Or a home network anyways. Basically, just got a home business that I deal with. Looking at the DHCP leases is basically just as easy as it would be to look on a home router. I quite I quite like this. Getting the DHCP leases out of something like DNS mask was not terrible, but not so easy either. And to be fair, to be fair, Samba has file storage stuff set up really well. It's very easy to create an SMB share on say Linux or anything else that Samba works on. I don't find that any easier to do on Windows Server, which is sort of weird to think about because you think that would be really, really easy to do on Windows Server. But yeah. And yeah, so I guess that's basically everything without getting into anything that would expose very serious specific details that could be used for hacking purposes or anything like that. It's basically everything I wanted to cover. I'm definitely not saying one system is better than the other that these are just the reasons why I switched, I personally switched to Windows Server. I can honestly say that if somebody were to just be like, Hey, I just need a simple file server. I don't need it to do much else. Okay, I could set that up really easy on Linux. Probably do that because then you're not paying a fat license fee. Samba works really well anyways. And it's pretty damn easy to actually, I don't even think it supports the very, very flawed version of one anyways. So yeah, you don't really need to fuck around with that too much. It's also really easy to get Samba set up to do NMB and WINS stuff as well. It's not that hard to get Windows Server up, but you know, it's really easy to do and you're not paying the fat license fee. I can also definitely say that if somebody were to need a just like a web server, it's very easy. And I would recommend something like Lightyear Engine X under for that one probably NetBSD just because it handles some load stuff better than Linux does. But in either case, you've got an excellent system that's very easy to set up and you're not paying the fat licensing fee that Windows Server involves. But for my needs, Windows Server wound up being the better option. I'm actually quite happy with this. I need to do almost no maintenance in when I changed this over about a month ago. And I, yeah, I'm a lot happier with this. There's one thing I thought of just as I stopped the recording. If you were in a situation like this, and I've already removed the Hyper-V switch before I even did this, I just I was going to mention it and I totally forgot over the course of that. If you are in a situation like this where you are running Hyper-V on the same machine that is a gateway. So like if we go back to this, you can see that normally for you to get the virtual machines internet access, you would set up the virtual switch on the public interface. The one that can actually reach the internet. Don't ever do that in this situation because you will lose all internet connectivity. Yeah. What you actually do is totally counter-intuitive, but you create an internal switch and bridge it with the with the stuff that shouldn't actually be reaching the internet because it's your intranet instead. So walk you through this because it confused the hell out of me and I could find literally no resources available for explaining how to do this. So this is going to help somebody. Like I said, I removed the switch. So we need to create a new one and it's an internal switch. One that would normally not have any internet connectivity and you leave it internal. You do not connect it to any external network. What you would normally do, you don't do that. This should not wind up actually that's not how you check. Why did I do that? You should see. Yeah. So the FE80 and 169.254.101. Actually I can't remember what that part is, but these are both local only, like auto configuration addresses. These are not routable. So what you then do is, that was weird, but oh no that's not. I have that already set up in routing. That's yeah. It defaults to it being public until it can try to identify it. Until it's done trying to identify it. That's just how I have it set up. What you do is actually add it to the bridge and then as odd as that whole thing is, let's just turn that off. Yeah just forcibly turn it off. I'll be able to show you in here. Oh no I won't because I need to add it. Also I hate the toolbar. So remove that. Okay that one didn't work which is actually surprising which means were you not told by the DHCP server what the DNS server was? Because everything else is. But I can pay out to the greater internet too. Totally weird, but yeah that's what you actually need to do. There is one thing I think you've got to make sure is done. I did this by default anyway. Oh okay I guess I guess you don't actually need to do that. I was thinking that you need to tell it that itself is the gateway but clearly that wasn't there. I must have forgot to type. Oh no because I tried to use the loopback address before and it just removed it but yeah. So I guess you don't even need that. I guess just adding it to that bridge alone is enough for it to still connect to the internet. So yeah if you've got Hyper-V on the same machine that's the gateway that's how you actually get it to connect because like I said if you connect it to the WAN the whole thing just you lose all internet.