BRRABill's Field Report With XenServer
-
@BRRABill said:
I thought using RDP to manage servers was a ML no-no.
You aren't using it to manage the servers, you are using it to install them and you aren't connected to the server with it, but to the platform.
And it IS a no no regardless, you should not be managing a server post install from the console at all. RDP is a no no because you should not be at the console.
-
@BRRABill said:
I thought using RDP to manage servers was a ML no-no.
I'm wondering where that came from?
While I do try to use RSAT whenever possible, the convinence of RDPing into a server sometimes just can't be beat.
Heck i was just RDP'ed into my Exchange and AD1 servers...
-
@scottalanmiller said:
And it IS a no no regardless, you should not be managing a server post install from the console at all. RDP is a no no because you should not be at the console.
To me saying this is tantamount to saying that you should never SSH into a Linux box - instead you should be sending remote commands to the Linux box.
-
@Dashrender said:
@BRRABill said:
I thought using RDP to manage servers was a ML no-no.
I'm wondering where that came from?
While I do try to use RSAT whenever possible, the convinence of RDPing into a server sometimes just can't be beat.
Heck i was just RDP'ed into my Exchange and AD1 servers...
It's not a very strong thing. But it goes against modern philosophies from all sides. On the "good systems admins" side, tools like RSAT and PowerShell are supposed to be better. On the DevOps side, you never log into to anything, ever.
RDP becomes a no no because in either of those ideal cases, the GUI isn't even installed so RDP gets you nothing but an expensive command prompt that PowerShell is better at, anyway.
-
So it really comes down to a GUI vs non-GUI thing again.
But, for example, Server 2003 ... there is no other option.
-
@Dashrender said:
@scottalanmiller said:
And it IS a no no regardless, you should not be managing a server post install from the console at all. RDP is a no no because you should not be at the console.
To me saying this is tantamount to saying that you should never SSH into a Linux box - instead you should be sending remote commands to the Linux box.
No, it's tantamount to saying you should never fire up X on a Linux Server and I've never met a real Linux Admin that didn't agree.
Basically, if you hold Windows to the same standard as the 90% or more Linux Admin community, you never RDP, you PS. (RDP is equal on Windows and Linux here, equally possible and equally treated.)
-
@BRRABill said:
So it really comes down to a GUI vs non-GUI thing again.
But, for example, Server 2003 ... there is no other option.
PowerShell, RSAT.... what are you doing in 2003 that the standard tools don't cover?
-
I'm not saying that you shouldn't make an exception for one old server that is going away... just saying that had you approached it from the no GUI mentality from day one, you could probably have been GUIless for well over a decade.
-
@scottalanmiller said:
PowerShell, RSAT.... what are you doing in 2003 that the standard tools don't cover?
Is 2003 available non-GUI?
When I click on console, that's what comes up. The GUI.
-
@BRRABill said:
@scottalanmiller said:
PowerShell, RSAT.... what are you doing in 2003 that the standard tools don't cover?
Is 2003 available non-GUI?
When I click on console, that's what comes up. The GUI.
No, but you didn't need to log into it.
-
@BRRABill said:
@scottalanmiller said:
PowerShell, RSAT.... what are you doing in 2003 that the standard tools don't cover?
Is 2003 available non-GUI?
When I click on console, that's what comes up. The GUI.
Don't think that's what he means... He means you could have been doing things like making new users, new file shares, etc.. all from the command line instead of using the GUI.
-
But you could remove the GUI going back to NT 4 at least...
http://www.techrepublic.com/article/starting-your-windows-server-without-a-gui/
-
@scottalanmiller said:
But you could remove the GUI going back to NT 4 at least...
http://www.techrepublic.com/article/starting-your-windows-server-without-a-gui/
Would you stop? I already learned my one thing for the day about XS and RDP
-
@Dashrender said:
@BRRABill said:
@scottalanmiller said:
PowerShell, RSAT.... what are you doing in 2003 that the standard tools don't cover?
Is 2003 available non-GUI?
When I click on console, that's what comes up. The GUI.
Don't think that's what he means... He means you could have been doing things like making new users, new file shares, etc.. all from the command line instead of using the GUI.
Exactly. All of the GUI-less tools were robust by 2003. That the GUI was still provided and the only option was because the 100% GUIless world across the board was not quite ready yet. But pretty much any normal shop had the option. It was extreme edge cases that had to use a GUI, unless you were running Exchange.
-
@scottalanmiller said:
Exactly. All of the GUI-less tools were robust by 2003. That the GUI was still provided and the only option was because the 100% GUIless world across the board was not quite ready yet. But pretty much any normal shop had the option. It was extreme edge cases that had to use a GUI, unless you were running Exchange.
I still contend for smaller shops that do very little admin tasks, the GUI is the way to go.
-
PUTS FLAME SUIT ON...
-
prepares to move to the moon
I don't understand the resistance to using the GUI in Windows... the RSAT tools are a GUI themselves, whether they are run remotely, or from the server's console (or over RDP) is little difference.
There are some things I can do faster in PowerShell remotely, and there are others that I am faster RDPing into a server and doing it in the GUI or from PowerShell on the server.... and in cases of my current environment, the SysAdmin machines are not joined to AD (I can understand this to some degree).
The Windows World, for as long as I have been a part of it has always been about the GUI -- especially from Windows 95 and on. If you feel more comfortable RDPing into your servers, a properly secured RD Gateway is just as good as a Linux / SSH Jump box (arguably, you could use a jump box for Remote Desktop as well with software that supports it).
Now as of late, the Windows world has begun a transition to "gui-less" servers, to reduce attack surfaces, and such. I think that's a great Idea, but I also recognize that some Windows SysAdmins will simply never be comfortable in PowerShell, and they will always prefer a gui. As time marches on, I think that number will shrink.
Even in the Mac world, the servers are largely GUI-driven... It just goes back to the base of the OS and what the SysAdmins are comfortable with.
Enter the Penguin: Linux servers, by and large, in my career have all been GUI-less and managed via SSH, which has been great. It's fast, and offers similar protections to disconnects as RDP (tools like screen and tmux come to mind). Linux systems, to me, make sense to manage.
There's not much to say about remote management in the Linux world, because it has been around for so long, and exists just the same in the "servers" vs a system with X installed -- SSH works just fine for Linux, and I doubt that will change any time soon. Of course now there are tools like Ansible, Puppet, and Chef that can help with management as well.
-
@BRRABill said:
@scottalanmiller said:
Exactly. All of the GUI-less tools were robust by 2003. That the GUI was still provided and the only option was because the 100% GUIless world across the board was not quite ready yet. But pretty much any normal shop had the option. It was extreme edge cases that had to use a GUI, unless you were running Exchange.
I still contend for smaller shops that do very little admin tasks, the GUI is the way to go.
I don't agree but it's for business, not technical reasons. If you had a shop managing a server that only does it once in a while, yes, a GUI makes sense. What doesn't make sense is a shop doing that. Why would you have someone manage a server only once in a while? That means that you either have to have that person maintain a set of skills that are very difficult and expensive but not leverage them while they also have to maintain other skills and use them all of the time. How can they be either good at their job or cost effective? You pay a premium to get a minimum.
This is just not a scenario that should really happen. This is what I often point to as the "one fundamental non-good practice leads to what appears to be good logic for doing others". Because we start from the assumption that we have a strangely inefficient IT structure, we then start doing other weird things based on that assumption. Therein lies the rub.
If, instead, you have an IT design where people were doing dedicated tasks you would not only have lower cost people (because paying one person to master multiple things makes them crazy expensive) but more focused, trained and efficient ones. A full time Windows Admin has massive advantages over a part time one - they don't task switch as much, they get more experience, deeper knowledge and will not just do things faster, they will be more aware of common mistakes, best practices, tools, etc.
That full time person doesn't just make things better on their own, they also start moving you towards better tooling and processes. Instead of saying "it's too costly to learn PowerShell for this one task, I'll never recoup the learning time" they already know it and you get the benefits of that. You get layers of greater efficiency plus deeper knowledge and experience.
-
@dafyre said:
The Windows World, for as long as I have been a part of it has always been about the GUI -- especially from Windows 95 and on.
It is important to remember that the Windows NT world is what we use, not the DOS/Windows world that Windows 95 was a part of. Core administration on the DOS/Windows world always required non-GUI skills, they never really overcame that.
In the NT world, they tried going all GUI and learned very quickly that this made them non-competitive. Things were hard to do, hard to learn, slow to be done, the systems themselves were very slow... they almost immediately began trying to fix this. By Windows 2003 they had essentially made the GUI old hat and had announced that the Windows world was a GUIless one in the future. By 2008, the GUI was a fallback only and not the primary management system by intent (as in, MS' best practices were to go GUIless and use remote tools.)
So the only real window of GUI-centric from Microsoft was 1994 - 2003, nine years, but only nine years and NT was only dominant from 1996 onward, so more like seven years. That seven years, MS took quite a beating and it remains the period that makes people look down on them as not being a serious OS even though since then the product has been awesome.
The idea that Windows is GUI based or GUI-centric comes from the "1998 Problem" that we see so much in IT. So much of what we know was solidified in that year and passed on generation to generation and people stopped questioning it. But like RAID 5 spinners and split arrays for databases and Parallel SCSI and running physical installs... using a GUI for administration finally gave way in the Windows world to bring it in line with the big iron world from the era before.
-
@dafyre said:
Now as of late, the Windows world has begun a transition to "gui-less" servers, to reduce attack surfaces, and such. I think that's a great Idea, but I also recognize that some Windows SysAdmins will simply never be comfortable in PowerShell, and they will always prefer a gui.
This is a huge difference in the Windows and Linux world. In the Windows world, they still call them system admins and act like it is okay. In the Linux world, while GUI and GUIless exist in identical ways, the culture is that if you need a GUI, you aren't ready for entry level systems administration. The communities hold themselves to different standards.
The reasons why no GUI are myriad. But here are some:
- In the non-virtual world (where Windows lived longer than any other OS) the overhead of a GUI is trivial. In the virtual world, it adds up. When Linux can install with 11MB of RAM, the Windows GUI suddenly looks very, very bloated. That GUI can cost rather a bit of money when you start pricing it over time. It adds a small need for additional CPU, a small need for additional storage and rather a large need for additional RAM. Just look at NTG, our average Windows install uses 400% of our average Linux install. 400% is not trivial. And we have some Linux at half that, but no Windows at less (if it has a GUI.) Moving to Windows Server Core or even Windows Server Nano are critical to Windows being performance and resource competitive. Take this to the IaaS world and the cost of the GUI explodes. It can often double costs.
- GUIs mean more code, often more than double the code, and more code means more risk and more patching. GUIs cause patch cycles, patch risks and everything related to increase. You have more to patch and more to go wrong.
- GUIs mean more bandwidth. Trivial for most shops today, but as a remote worker I feel this tremendously even today. Every time I have to use a GUI I feel pain. Pain of waiting, of unresponsiveness. GUIs lower your flexibility and options while increasing the hit on your bandwidth.
- Based on the above there is additional risk, GUIs can update a screen more slowly than they have changed input parameters. GUIs make it easier for a mistake to be made that falls completely on the interface, a new type of risk. It's uncommon but many of us have seen it where we chose one thing and we've actually clicked somewhere else because the GUI was updating beneath the mouse. For an end user, this is trivial. For administration, this is huge.
- GUIs are fragile. Both Windows and Linux, doesn't matter, the GUI fails more often than the rest of the system. It is big, it is complex and it has to do complex things. Everything from desktops to servers the GUIs are more likely to fail and more likely to cause other things to fail.
- Common Denominator of Administration: you don't always know what you will have when you deal with a new machine. This is why on Linux we teach people to use BASH, vi and similar tools because you know that you will have them every time, no matter what system you are on. You will always be able to do your job. For Windows, this means PowerShell. Just because all of the systems you use today have a GUI doesn't mean that they all will tomorrow. Maybe a vendor won't support Windows with a GUI. Maybe you need to do a new job or support a new system or move to IaaS and the cost is too high with a GUI. GUI dependency puts the unknown at risk.
- GUIs are not available on all platforms. Not all editions of Windows support a GUI. If you need a GUI, you lack that ability to use. Limited (today) but an increasingly likely thing. What if Windows Server has no GUI in the future for any version?
- GUIs have a bigger attack surface.
