Episode 17, Solaris

PodCast Feed


Links:
Sun Solaris
NFS
GNU
Sun Solver
Open Solaris
Sun Certified System Administrator (SCSA)
Solaris Zones



RYOS, Episode 17 - Solaris

Seg: Thank you for joining us here on another fantastic episode of the 'Run Your Own Server' Podcast. I'm Seg, over here to my -- well, I don't know really where he would be in relation, network wise, but Thud is on the other side.



Thud: Hi, I'm Thud.



Seg: Yup. I'd like to say hello and thank you to everyone who has joined our forum and posted messages about stuff. Hello, and thank you for your support.



As the leader of the group when it comes to Solaris, I'm going to be doing most of the driving, I guess. I've been using Solaris for about four or five hundred years now, and I really only have experience with Solaris nine and Solaris 10.



If you want to be a Solaris admin, well, you've got some surprises in store for you. It's nice to be a Solaris admin in the sense that anyone who can afford Sun hardware and Sun support is probably going to be able to afford to pay you very well. At least, that's the theory because Sun equipment is very expensive; even second-hand stuff is very expensive. Just hit up eBay and you can find systems that equate to 386s in desktop terms are several hundreds of dollars. They're insanely over-priced just because they're Sun hardware.



If you're a Solaris Admin now, you're most likely running Solaris 10 or Solaris 9. Anything older than 8, though, you should really think about upgrading as soon as humanly possible.



Solaris 10, I'll talk about most because I know it the best. Solaris 10 is a 64-bit operating system. You may have heard the hype about 64-bit taking over the world, how everything is going to be 64-bit and be so awesome. What you might not know, even if you are a Solaris admin, is that most of the applications that run on Solaris 10 in the 64-bit kernel are, in fact, 32-bit apps, and they run very well, actually. Sun has done a very good job of making 32-bit applications run under a 64-bit kernel.



Now, I engaged in a project -- not that long ago, just a couple of months ago -- to compile programs in 64-bit mode to see if they would run any better under a Solaris 10 64-bit kernel. Across the board, every single application performed worse in 64-bit mode than it did in its native 32-bit mode. The reason for that is if you were to take, if you remember the old Nintendo entertainment systems, like the old ones, the original NES, take one of those cartridges and somehow get it to work on a PlayStation 3, it's not going to run very well. You'll have to clock down the PS3 to make it work at the level of the 8-bit cartridge that you just plugged in.



That's pretty much the way everything works in a 64-bit world. You get the same thing with 64-bit Linux and 64-bit Windows. There's a lot of -- it's been called "sex appeal" about 64-bit, and a lot of hype. Well, "everything can be faster, everything can be better in 64-bit," and it's not. The only thing you get in 64-bit mode is more memory space. As long as the application has enough memory space in 32-bit mode, then there's no reason to worry about it. The kernel for Solaris runs in 64-bit mode because all of the hardware is 64-bit, and the kernel is built to take advantage of that extra memory space and to maximize its performance under the hardware conditions.



Talking about cache, like I said, Sun hardware is extremely expensive. You can get a couple of good deals right now on Sun x86 hardware; they have things like the x2200. You can get a pretty good deal on that stuff, but you'd get a good deal because it's total crap. [laughter] I don't want to lie to you guys; it's total crap. Ever since they started putting out the Cool Thread servers and the x86 stuff, it's just going downhill. There's been some really, really dumb mistakes made on Sun's part in regards to hardware, and don't even get me started on the T2000 series!



Anyway, it's still extremely expensive across the board. If you want a really good machine, even the x86 stuff, which is crap, if you want a good one you're still going to be paying a pretty hefty price when compared to the actual Intel hardware or the Intel-compatible hardware that you can get.



Thud: Now, is it expensive because it's better? Why is it expensive?



Seg: It's expensive because it's a monopoly! [laughter] It's only sold by Sun, eBay, and resellers.



Thud: OK, so it's not necessarily any better than anything else you could get.



Seg: Yes, it's because you're getting it directly from Sun, theoretically, because it's Sun hardware. That's why it's more expensive. Sun hardware is very expensive because you get it from Sun Microsystems, a reseller, or eBay. But that's really the only way you can get it is from Sun or second-hand from Sun. There are no other companies out there making Sun SPARC hardware in the sense that you can buy any kind of processor, motherboard, or something, and it's Intel-compatible. You can't go out and build your own motherboard that will be SPARC-compatible -- well, you could, technically, but that's beside the point.



Another thing that you need a lot of cash for is Sun support. You buy hardware directly from Sun; that's great, you get a little warranty on it. But if you want real support, if you want software support, you're going to have to pay through the nose. Most times, 99 percent of the time, you're going to pay a lot more for support than you are for the hardware, and that's saying a lot, considering how expensive the frigging hardware is.



A lot of people choose not to go with the support. They just say, "Well, instead of spending 30 to 50 to 60-70 thousand dollars per contract year for support, I'll just hire me a Sun admin and buy parts through eBay if needed." That's fine; it works out for a lot of people, and it certainly employs a lot of people outside of Sun, which is fantastic considering I'm one of those types of people!



Unfortunately, the community support for Sun is very small. If you're using FreeBSD, for example, and you can't figure out how to change your password, well, there's a million different sites out there that run forums, newsgroups, and mailing lists, where you can ask questions and get a lot of support. But there really isn't that kind of an environment for Solaris. There's OpenSolaris, which is a lot of things, and one of things that OpenSolaris is a group for support. There's Sun Managers and there's a couple of third-party forums out there, but there's not the type of open source community support for Solaris as there is for anything else out there, such as Linux or BSD, or even Windows.



So, if you're a Solaris admin, 90% of the real support you're going to get is probably going to be from Sun Microsystems Incorporated -- Sun directly. Again, that can cost an arm and a leg.



Sun does have a lot of different levels of support, though. You can get system support, which is OS support just for their certain system and it's hardware support for that system. It's like total support just for that one system, and you can pay per system. You can also get software support only, but you still have to give them serial numbers of the servers. They have a lot of different tiers and stuff, and if you talk with their sales department, which I've had to do over this year or so, in theory they have a lot of different options. I'm going back and forth with them right now over something so I don't have a lot of faith in it, but I'm sure once it's all resolved, I'll be able to say yes, they're fantastic.



Now, if you're used to running FreeBSD, OpenBSD, Linux, anything within those operating branches, you're used to using a lot of GNU tools, and you probably don't even know about it. Things just like tar, patch, top, and tons of stuff, that's standard. If you install FreeBSD, you get GNU tar; that's the tar, that's what it is. It's the GNU version of tar.



When you install Solaris, though, you get the Sun version of tar, which is extremely different from the GNU version of tar, and the same thing for grep. This can cause some headaches for a new Solaris admin, finding all the little utilities that are Sun version, and they don't have all the nice bells and whistles that you're probably used to that you get with the GNU versions.



There are plenty of times where I had to beat my head against the wall for a couple of minutes before I realized, "Oh, that's right. I'm using the Sun version of this instead of the GNU version of that." The latest time I ran into that was patch -- the patch utility.



If you're familiar with patch at all, one of the functions of patch, really the only thing I've ever used it for, is you have an application that comes in source code, you're supposed to compile that source code to install it. Well, before you even compile it, you need to apply a patch. So, you download another thing of source code, put the source code in a certain directory, the application in a certain directory, and you tell patch apply this patch to this source code, and then I'll build the application and the patch will be included in with it.



We'll there's a difference between Sun's version of patch and the GNU version of patch. I was patching PHP, I was adding a hardening patch, and the Sun version of patch just blew up. It just gave me the middle finger and wouldn't work at all. It was like, "Why isn't that working. I've gotten it to work on FreeBSD a thousand times. I don't understand." Finally, I remembered there must be a different patch utility for Solaris than there is for everything else in the world. There was, and I had to go download the freeware version of GNU patch and install that.



So, you always have to look out for those gotchas, the differences between Sun and the rest of the entire universe.



Thud: If I can butt in here?



Seg: Sure.



Thud: If it's that difficult, if there are things that are that different, why would you want to use Solaris in the first place?



Seg: I don't want to answer that question because it undermines my job! [laughter]



Thud: Oh, OK. That's a perfectly valid answer. [laughter]



Seg: I don't want to think about how horribly I have it in my life. [laughter]



Well honestly, once you get past the initial gotchas, there are a lot of nice things about Solaris that you don't get with other operating systems. The support, when you get it, is fantastic. Although the SunSolve site doesn't work as fast and as stable as I'd like it to be, when it does work, it works great. Sun is regularly releasing patches for their software, keeping you up to date.



If you run FreeBSD, you can't really get an authoritative answer on a really complex issue, like a kernel issue for production level. You could query the mailing list that deals with kernels in FreeBSD, and maybe you'd get a developer and he might point you in the right direction. But with Solaris, if there really is a bug in the kernel, you can actually get the kernel team on the phone and they can work with you through it. It will cost you an arm and a leg, but that's a real option.



The worst, I guess, you could probably also say that well, if you paid the FreeBSD people that kind of money, they'd probably do it for you, too. [laughter]



Thud: Yes, but at least with Solaris it does sound like you're getting a higher level of support that you can really rely on.



Seg: Absolutely.



Thud: FreeBSD and all the other open source operating systems have a huge community of support, but it's really hard to sell that to a boss who doesn't understand that.



Seg: Yes, yes.



Thud: All right. Well, let's move on to the next thing. Sun, of course, is standardized on Apache because it's the most used web server there is, so of course, they include it in Solaris, right?



Seg: Yes, actually they do. If you do a full install of Solaris 10, you get Apache and Apache 2. The version of Apache two is not the 2.22, I think is the latest for Apache; it's the branch right below that, like the 2.0. It's pre-compiled; it installs as a package. It's, in theory, compiled to be best optimized on a Sun system, which is great. Of course, I never use it because I always have to recompile Apache for different options and stuff.



Thud: Yes.



Seg: But the Sun version of Apache is a little bit different than the version people are usually used to. I don't know, I think there was one project that I have ever worked on -- it was extremely small -- where I used the packaged version of Apache. Other than that, I just had to host one page on a website, and it was straight HTML. I didn't want to bother with compiling Apache, I just used the native Apache and I ran at that way. But for every other application I've ever needed it, I've always had to compile my own.



But prior to releasing Apache standard with their OS, there was the Sun One Java Web Server, which is still available and still packaged. The Sun One Java Web Server is Sun's idea of a web server, and it's frigging terrible. I would not recommend it for anybody. [laughter] Yes, it's bad.



Well, Java is bad, really. I don't like Java; I hate Java; I hate JavaScript; I hate PERL. I'm sure we just lost half of our audience, but I really can't stand Java. [laughter] I get it that it's cross-platform, and I understand its scalability is fantastic; but no, I just hate Java.



Thud: Yes, I'm kind of with you on that one. I definitely do not like Java. [laughter]



Seg: Well, they have a Java web server, and they have a Java application server. Two very separate things, but again, they are packaged along with Solaris. But I think that in most cases, people are going to look at that and say, "That's nice, but I'm just going to compile my own; I'm just going to install my own Java." But yes, you've got to look out for things like that.



An important thing to note if you're going to compile your own Apache on Solaris. If you do a default install of Solaris, you'll get both versions of Apache, and then you'll want to install your own, so you'll end up with three versions of Apache. There will not be any conflicts as long as you install it into a separate directory. Apache and Apache two on Solaris install directly in the user directory, so it's /usr/apache, or /usr/apache2. That's where they install.



Most third-party apps will go in user/local, so if you install your own build of Apache into /usr/local/apache/whatever, it will not conflict with the Sun versions. The same is true for OpenSSL, which most people will be using on a web server if you want to use encryption port 443, all that good stuff. If you install OpenSSL into usr/local, first off, it will not conflict with the native SSL that comes with Solaris, it will not conflict with the OpenSSL version that installs with Solaris. It will not conflict with any of those.



Solaris does come prepackaged with some GNU tools, some freeware tools, and they will install in different places such as usr/ccs/bin -- you'll get the executables in there -- usr/sfw, and then there's a bin and an sbin and stuff off of that. So, you will get some real-world applications in those places.



The OpenSSL that comes with Solaris, which is the free version of SSL, that will install in usr/sfw/ssl. So, if you install in usr/local, it will not conflict with that. You won't have any conflicts, and it will be fine. You'll just have to reference the libraries when you build stuff, and when you call the libraries you have to direct them to the right version of SSL that you need.



One of the cool things that came through with Solaris 10, which was not available in Solaris nine and previous, was NFSv4. If you don't know anything about NFS, then just ignore me for the next five minutes because you don't need to know anything about NFS. If you know what NFS is, and there's a gun held to your head and you need to use it in order to keep breathing, then think about the quality of your life, and if you're more than 50 percent sure that you need to live, then keep on listening.



NFS is network file system -- network file sharing, and it's a way to mount a partition over a network. It's like SMB shares with Windows. Well, NFSv4 brings a lot of cool bells and whistles, one of them is it will now work over TCP. It will also run on low ports; instead of using 50,000 ports all across the spectrum, you can now force it to run on lower ports making it a lot easier to work over firewalls. Also, you can get encryption and a bunch of other stuff, although encryption is kind of stupid. If you're in a situation where you need NFS encrypted, you don't need to be using NFS. [laughter] You should be using something else. But that's not the point.



In practice, and Thud and I have actually seen this in real practice, if you run NFS and you want to use TCP, I say go for it because, in practice, TCP will actually work better than UDP. Now I know what you're saying, "Seg, but UDP is faster because you don't have to wait around for a reply." Well, NFS sucks. So, if you can use TCP, you can guarantee the package are getting there -- how they need to get there. You are actually going to run a faster environment; you're going to run a more stable environment than UDP. So, if you have to use NFS -- forced to, gun to your head, all that -- go with version four forced TCP, I think you're going to be happy with the results.



Thud: Or, you could always take my advice: if NFS is the answer, you need to change your question. [laughter]



Seg: Ah, Thud. Always the wisdom from you! I've got to write that one down. [laughter] Oh, that's beautiful!



Thud: OK, why don't you tell us about -- I don't know. What do you want to do next? Sun's SSH, or...?



Seg: Yes, Sun doesn't really have SSH. Sun has just incorporated OpenSSH.



Thud: But of course it's a little different.



Seg: Of course it's a little different, yes! [laughter] If you go out, and you get SSH from the OpenSSH Group, and you install it, the config file is completely from that which you get on a Sun install. So, you will have to read the man page, and you'll have to figure out instead of using, if you don't want the IP to be resolved when you connect, it going to be the user DNS switch, or is it going to be resolve/client/host name switch. It's the same thing, but with a different name. So again, you're going to run into gotchas with that.



There are other SSH servers out there; there's SSH Server 2, by the Tectia people, I think that's name of their company. And again, their SSH-D config format -- file format is completely different from everything else. So, it's just another gotcha, really.



Thud: All right. So, I guess Solaris is different in a lot of other ways. How is it different when it comes to patching?



Seg: Well, I still run FreeBSD in a lot of servers, and I don't really patch it that much. This is all internal stuff. It never sees the light of day; it doesn't touch the Internet. If you want to patch a BSD system, it's not really patching, you do a CVS upgrade on all of your installed programs. And that's really cool, it's this utility that goes and looks at what you have installed and then downloads the new versions of that. If you get it set up right, it's pretty nifty.



The Solaris equivalent to that doesn't really exist. Well, [laughs] it does, but I'm not going to get into it. Patching on Solaris is actually pretty easy. It's even easier on Solaris than it is on FreeBSD. About every two weeks, Solaris puts out a bulletin saying, "We've updated our patch cluster, you can go download it. Here are the newest fixes."



So, you go to SunSolve with your paid SunSolve account, and you download a patch cluster. And they range from 400 to 700 megs each--I think that's right--no, about maybe 200 to 400 megs, depending on the OS level. You download it from Sun, and it's a ZIP file--it's just a single ZIP file--and you copy it to your system and you unzip it. And then you CD into the directory that it creates, and you run a script that's called install--cluster.



What that does is it goes through every patch that it has there, which is all the patches for that OS that are security-related and recommended by Sun. They're not all the patches available for that release, they're just all the ones that are critical and that are believed to be non-harmful in Sun's eyes. And I'll talk a little bit more about that idea in a second.



Anyway, in theory, it's pretty simple: you download the file, you unzip it, you boot down into single user mode, and then you run a script. And it takes like an hour to two hours, or however long it takes, whatever kind of system you have. It goes patch-by-patch and says, "Is this installed? Yes, patch it. If no, don't. Try to patch this; if it fails, let us know." Stuff like that. But that's it. The actual patch process is hands-off once you install that script.



And then after it's done, you do a reconfigure reboot, and, in theory, everything comes back, it's all patched, and you're good to go for another two weeks.



In practice--well, I'm not going to say across the board. For me personally, in practice, patch clusters sometimes blow up servers. And I've become quite adept at being a disaster recovery tech for Solaris because of patch clusters.



On a default install that's not been meddled with too much, the patch clusters will work just fine. But I've had to work with a lot of customers who have, for whatever reason, done some really, really weird stuff to their system, and the changes that they've made, they didn't seem to be too bad when they made them, but just one bit in one file somewhere deep in the architecture got changed, and it just totally hoses the box after you run a patch cluster.



Because of this, [laughs] you need full backups before you run them. If you're using a RAID, if you're using a mirror for the root disk, I recommend you break the mirror before you do a patch cluster: you have a rollback. You really need to be careful.



When I first got into patching with patch clusters, I thought it was the best thing since sliced bread. I was so gung-ho about it, I'm like, "Yeah, this is great! It's really easy. We'll patch everybody, keep them all up to date. It's fantastic!" And then about four or five customers in, I blew up a box. [laughs] I was like, "This is not as good as I thought it was."



[Thud laughs]



And so I backed off a little bit, and I got a little wiser. But in theory, it's a lot easier than other operating systems, and I believe, at least in my situation, that the sleepless nights I've had to spend rebuilding boxes and reverting problems has been a learning experience and a very positive thing. Although the customers were not too happy; but they're never going to be happy.



All right. Here's one of the neat things I like about Solaris and Sun systems. Again, I want to do a comparison. On an Intel box, you've got the BIOS. During the boot process, you can interrupt the boot process, and you say, "I want to look at the BIOS, and I want to change some really arbitrary value on some switch I have no idea what it does. And then I'll reboot, and I'll hose my box." [laughs]



On Solaris, you have up to four different BIOSes you can mess things up on. [laughs] It's fantastic. The boot process--and this varies slightly between different models of systems--I'm going to take, for example, a Sun Fire V240, which is one of the systems I'm most familiar with. A Sun Fire V240 has ALOM: ALOM stands for Advanced Lights Out Management.



If you plug a 240 into a power socket, but you don't power it on, and you connect something to its console--you can do a straight CO connection to a laptop, or you want to run it through a Cyclades switch, however--if you connect to its console while it's powered off but has power connected to it, you can access the ALOM: the Advanced Lights Out Manager. On older systems, it's called just LOM: Lights Out Manager.



In there, you can change some system values. You also have the ability to send a break to the system. At that time, the power would be off, so it really wouldn't be useful. But anyway, you can do things like power off and power on the box from a little management interface, and it's pretty cool. You can also set boot values. You can override a couple of things later on down the boot process. It's extremely useful, at least in my line of work.



If you are at the management console and you tell it, "Power on, " then it'll power on and start to boot. Once the boot process exits ALOM, it goes into POST--Power-On Self-Test--and all computers have a Power-On Self-Test. It's a hardware-level test where it just goes through and says, "OK, everything that I can find responds to some basic tests, and I believe it to be good, so let's keep on going."



After the POST section of boot, you get to the OBP--the OpenBoot PROM--which, again, is another thing that you can actually get an interface on and change values. There are a number of variables set in OBP that you can change. You can modify things like what the default boot device is going to be.



You can pass certain command switches: you could say, "Well, I want to boot from the network or from the CD-ROM, and I want to do it in single user mode, " or, "I want to boot from a disk and reference this file, instead of booting normally." You can also change things like the banners: you can put a logo on there. [laughs] And these are all really kind of interesting and kind of neat--I know they're not huge system changes--but there is a lot of fun stuff in the OBP that you can change.



Now, after the boot process, if you're letting it go, after it exits OBP, it goes into the actual disk boot or net boot or CD-ROM boot, the actual device that you want to boot from, and then it continues the boot process from there.



If you're connected over the serial port, the serial console, you can do a lot of fun things on a V240. If the system is up, if it's completely up and running and applications are going, you can connect to the serial console and then pass a command -- which, on a V240, it's "pound period" and then hit Enter a couple times. You will be given the ALOM prompt, the same thing that you saw at the beginning of the boot process before it was even powered on. You can have access to ALOM while the system is running. You can only do this over the serial console; you can't SSH in and do this.



From there, if the system's not responding, if something at the application level is borking the system and you can't get a login prompt or anything, you can still get into the ALOM, and either you can force the power off, you can force it to reset, you can also send a Break to the system. A Break or a Stop-A, as Sun techs are familiar with, is a way to say, "I don't care what's going on, you are to stop execution of the entire kernel right now, drop down to the OBP prompt." And again, talking about the OBP prompt a couple seconds ago, that's a fun place where you can change variables about how you boot.



On a V240, let's say I wrote a Java application, and as Java applications do, they blow up. It's just completely hosing the system, so I need to reboot, but I can't get down to the system to do it -- but I do have console access over our network. I will log in to that console access, I'll access the ALOM, I'll say, "Send a Break to the system." It will send a Break, I'll be dropped to the OBP prompt, also called the OK prompt. I can change how it boots. Let's say, if it was screwing up, I want to boot from the network and rebuild the box, or if I want to boot from the CD-ROM, whatever. I can do that from there and then reboot. And if it screws up again I can send another Break, and keep doing the same thing until it works.



Here's a fun question. If you're ever interviewing somebody for a Solaris position, here's a fun question to ask: 'Why is the OK prompt mislabeled?'



Thud: Because if you're at it, you're not OK?



Seg: Exactly. That's exactly right.



Thud: Cool!



Seg: The OK prompt is the OBP prompt, where you can change system values and how it boots. If you're there, in most cases, something's probably not going OK. [laughs]



Thud: The kernel's definitely not running at that stage.



Seg: [laughs] Exactly! There's a whole universe behind Sun Microsystems, Inc. Solaris is a gigantic operating system. It's a lot of fun and I believe it's really interesting, and I have a lot of fun working on it. My talking about it here isn't supposed to give you an in-depth view to how to become a Solaris admin. I just wanted to give you some tips, know what to expect if you wanted to head down that road, and give you a heads-up on some gotchas.



I really recommend going for the SCSA -- the Solaris Certified Systems Administrator certification. I've got it myself. I recommend going for that. Try to use a quality testing center, though. There were a couple of questions on the one that I took that were impossible. But go out, get a book. If you're going for your SCSA, get a Sun Support account. If you want to go buy a study book, that's fantastic, but for everything that you read about in the study book, also look it up on SunSolve, on docs.sun.com, and read what Sun Microsystems says about that topic.



If possible, get yourself a Sun system to practice on. An x86 will work, it'll be enough for the exam, but I really recommend going for a SPARC system. That way you can have access to the OBP. I didn't get tested on ALOM at all -- they didn't touch on that at all -- but there were OBP questions I did have to answer. So, I definitely recommend that.



[music]



Thud: OK, so for this episode's Moment of Seg we're going to go over a cool new feature of Solaris 10 called Solaris Containers or Solaris Zones. Take it away, Seg.



Seg: Thank you, Thud. Solaris Zones are Sun's answer to Virtual Machines and Jails in FreeBSD. A Solaris Zone is an encapsulated instance of the Solaris 10 operating system, running, in theory, separate from the global system. You can install a Solaris Zone kind of easily; it's just a few commands. The packages needed to run a Zone are included in the default full install of the Solaris 10 installation.



It wasn't really built for security. I would not recommend trusting a Solaris Zone to be secure, to be completely separate from the OS. Even Jails on BSD systems are not impervious to being broken out of.



But they're kind of neat, because if you want to separate applications in their own little Zones or groups, this is a neat way to do it while wasting a ton of system resources. A Solaris Zone installs through a couple of commands. First you set up a Zone, and then you install the Zone, and then you boot the Zone. You do actually have access to the Virtual Console on the Solaris Zone. There is actually a way to log in to the Zone as though you're logging in over the Console.



From the global Zone you can log in to a subzone, a regular Zone, but you can't log out of a Zone -- or under normal circumstances, you can't log out of a Zone to go to the global Zone. So it's like you have one big operating system called the global Zone, and then you have little tiny operating systems within that, running as their own Zones. You can name Zones and stuff like that.



I've used Zones to run different applications, segregated from the rest of the environment. They're useful because in theory, you are segregating processes -- so in theory, if the web server you're running in a Zone gets hacked, then it's not the entire system. It's very easy -- you can down a Zone, you can boot it down very quickly. You can wipe it and you can reinstall it within a few minutes. It's very quick to do.



So, if you wanted to set up just another layer of security, then I recommend going with Zones. But again, don't rely on them to keep your system secure. Just use them as another layer of security in your entire security plan.



[music]



Thud: For show notes or other details, please visit our website at RunYourOwnServer.org.



If you would like to send us feedback or have questions you'd like us to answer on the show, please visit our forums at forums.RunYourOwnServer.org.



The intro music, "I Like Caffeine," is by Tom Cody. This song, "Down the Road," is by Rob Costlow. Please visit our website for links to their websites.



This podcast is covered under a Creative Commons license. Please visit our website for more details.