4 ms·

In my experience, Windows tooling for serious admin work is either terrible or massively expensive/enterprise. For instance, a key problem I had in a prior gig

by pnathan 13y ago

In my experience, Windows tooling for serious admin work is either terrible or massively expensive/enterprise. For instance, a key problem I had in a prior gig was that I needed to automatically log into a Windows machine, run a job, and then log out. Pretty bog standard; didn't need careful error recovery or anything particularly sophisticated. In Linux, you configure your SSH keys, then ssh automatedjob@server -c "./run-my-thing", and that's that. I literally could not find any identical analog in Windows besides telnet (if anyone knows of a solution here that approximates the Linux one for simplicity, I'd love to know about it). Today I'd probably just requisition a copy of a Windows SSH server and be done with the sorry mess. Better yet, throw Windows out and go full Linux. ;-)

toyg 13y ago
Google PsExec.
dtauzell 13y ago
You can use remote powershell scripts to do the same. Configuring permissions is different, but is doable.
mfenniak 13y ago
A decent approach to doing this in the Windows world would be to use PsExec.exe (http://technet.microsoft.com/en-ca/sysinternals/bb897553.aspx http://technet.microsoft.com/en-ca/sysinternals/bb897553.asp...).
- pnathan 13y ago
  Ah, PsExec. Yes, I reviewed that. However, the issue with PsExec has to do with credentials. If you don't bother with the user/password, it impersonates your account, which has certain restrictions[1]. That was not feasible due to most interesting things living on network drives. If you do bother with the username/password, you have to store those somewhere (remember, automated system). So now instead of running psexec directly, you have to have a tool that grabs the password file, hopefully decrypts it, then runs psexec. Also, iirc, using the psexec interface from Linux in a Linux->Windows connection does not work (a wrinkle in the original story is that it was a Linux->Windows connection). [1] http://windowsitpro.com/systems-management/psexec http://windowsitpro.com/systems-management/psexec
  - AaronFriel 13y ago
    What, in practice, is the difference between creating an account and SSH key that gives passwordless sudo (or other authorization) and creating an account and password that gives appropriate authorization?
    - VikingCoder 13y ago
      You have to possess the SSH key, but any keylogger could record the password? Passwords can be guessed?
      - AaronFriel 13y ago
        If you have the ability to install a keylogger that can hijack a user session, what prevents you from capturing the SSH key of the user?
    - pnathan 13y ago
      I can generate a unique pair of ssh keys for each client that has to remote into a system; I have to have a consistent password for the same user across all systems (assuming integrated login). Supposing that a keyfile is copied, the multiplicity of ssh files limits the damage.
deleted 13y ago
[deleted]
mhurron 13y ago
Why did you need to log in to fire it off instead of having a scheduled job? Now, I was pretty sure you could use WMI to do this, and looking around I found this - http://4sysops.com/archives/three-ways-to-run-remote-windows-commands/ http://4sysops.com/archives/three-ways-to-run-remote-windows... and this http://blog.commandlinekungfu.com/2009/05/episode-31-remote-command-execution.html http://blog.commandlinekungfu.com/2009/05/episode-31-remote-... Remote PowerShell is probably 'the way' Microsoft will be pushing now http://msdn.microsoft.com/en-us/library/windows/desktop/ee706585%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ee70...
- pnathan 13y ago
  That's a good question. The best answer is that the configuration needs to be a version controllable artifact just as much as your code is. Further, Windows Scheduler is known to drop jobs from time to time[1]. What was happening is that there was a job controller running on Linux that needed to contact the Windows machine and boot the job into action. One solution would have been to install a Jenkins slave instance, which turned out to be the solution eventually adopted. [1] It's been a few years since I studied this, but it was a known issue in '08/09 or so.
beachstartup 13y ago
cygwin sshd allows you to do this as well as other unix-y things like rsync, scp, etc.
camradal 13y ago
It's definitely more work, but a lot of provisioning can be currently automated using Chef. It plays surprisingly well with Windows. We've developed approach using Chef that spans Linux and Windows boxes. To log in and run some script on Windows boxes, we use WinRM, which is integrated with Chef knife tool and works almost as well as SSH.
lifeisstillgood 13y ago
Psh I think is a viable solution (there is a pay for / shareware package of running a shell command on a remote machine) I seem to remember doing clever things with WSI for just such a thing curiously I am pretty sure there will be examples of both on StackOverflow ;-) Edit : oh yes WMI and psexec - amazing how quickly things drop out of your brain.
KyleBrandt 13y ago
Windows has advanced in a lot of ways over the past several years. We hired Steven Murawski a little while back (Powershell MVP) and he has been able to automate just as much as would expect in the Unix world. He is also priming out infrastructure for Desired State Configuration (configuration management (like Puppet/Chef) for Windows).
- pnathan 13y ago
  What I'm deriving from your statement there is, "So we hired a guru to bring our Windows systems up to par with Linux base point". I'm glad its working for you, I use stackexchange daily and am generally quite happy with it!
  - stevenjmurawski 13y ago
    Not at all. The Windows OS now has command line accessible management points that are similar to Linux. There is still a great deal of difference in their management models (I blogged about this a while back - http://blog.serverfault.com/2013/06/03/cross-platform-configuration-management-is-hard/ http://blog.serverfault.com/2013/06/03/cross-platform-config...) That I was hired as a Windows specialist was so that we can go deeper on the OS side and the PowerShell side, just as we have a Linux expert to go deeper on the Linux side. Our sysadmin team was just more tilted with experience on the Linux side (though you wouldn't know it - as almost everyone I work with would qualify as a senior admin in any Windows shop in the world).
    - pnathan 13y ago
      Steven, Thank you for your response. I am glad to see that there are comparable capabilities in the modern Windows world and will dig into the WMI side of things next time Windows admin tasks come up.
dvanduzer 13y ago
This kind of thing is easily handled with Kerberos. Joining Unix servers to AD doesn't require that you manage your entire Posix user database there. You can just use a Service Principal for this.
noblethrasher 13y ago
Windows supports VPN natively. * Set the firewall to only allow telnet access on a private subnet * Set the vpn connection to use that subnet * login from any computer that supports telnet and PPTP.

by pnathan 13y ago

toyg 13y ago

Google PsExec.

dtauzell 13y ago

You can use remote powershell scripts to do the same. Configuring permissions is different, but is doable.

mfenniak 13y ago

A decent approach to doing this in the Windows world would be to use PsExec.exe (http://technet.microsoft.com/en-ca/sysinternals/bb897553.aspx http://technet.microsoft.com/en-ca/sysinternals/bb897553.asp...).

pnathan 13y ago
Ah, PsExec. Yes, I reviewed that. However, the issue with PsExec has to do with credentials. If you don't bother with the user/password, it impersonates your account, which has certain restrictions[1]. That was not feasible due to most interesting things living on network drives. If you do bother with the username/password, you have to store those somewhere (remember, automated system). So now instead of running psexec directly, you have to have a tool that grabs the password file, hopefully decrypts it, then runs psexec. Also, iirc, using the psexec interface from Linux in a Linux->Windows connection does not work (a wrinkle in the original story is that it was a Linux->Windows connection). [1] http://windowsitpro.com/systems-management/psexec http://windowsitpro.com/systems-management/psexec
- AaronFriel 13y ago
  What, in practice, is the difference between creating an account and SSH key that gives passwordless sudo (or other authorization) and creating an account and password that gives appropriate authorization?
  - VikingCoder 13y ago
    You have to possess the SSH key, but any keylogger could record the password? Passwords can be guessed?
    - AaronFriel 13y ago
      If you have the ability to install a keylogger that can hijack a user session, what prevents you from capturing the SSH key of the user?
  - pnathan 13y ago
    I can generate a unique pair of ssh keys for each client that has to remote into a system; I have to have a consistent password for the same user across all systems (assuming integrated login). Supposing that a keyfile is copied, the multiplicity of ssh files limits the damage.

deleted 13y ago

[deleted]

mhurron 13y ago

Why did you need to log in to fire it off instead of having a scheduled job? Now, I was pretty sure you could use WMI to do this, and looking around I found this - http://4sysops.com/archives/three-ways-to-run-remote-windows-commands/ http://4sysops.com/archives/three-ways-to-run-remote-windows... and this http://blog.commandlinekungfu.com/2009/05/episode-31-remote-command-execution.html http://blog.commandlinekungfu.com/2009/05/episode-31-remote-... Remote PowerShell is probably 'the way' Microsoft will be pushing now http://msdn.microsoft.com/en-us/library/windows/desktop/ee706585%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ee70...

pnathan 13y ago
That's a good question. The best answer is that the configuration needs to be a version controllable artifact just as much as your code is. Further, Windows Scheduler is known to drop jobs from time to time[1]. What was happening is that there was a job controller running on Linux that needed to contact the Windows machine and boot the job into action. One solution would have been to install a Jenkins slave instance, which turned out to be the solution eventually adopted. [1] It's been a few years since I studied this, but it was a known issue in '08/09 or so.

beachstartup 13y ago

cygwin sshd allows you to do this as well as other unix-y things like rsync, scp, etc.

camradal 13y ago

It's definitely more work, but a lot of provisioning can be currently automated using Chef. It plays surprisingly well with Windows. We've developed approach using Chef that spans Linux and Windows boxes. To log in and run some script on Windows boxes, we use WinRM, which is integrated with Chef knife tool and works almost as well as SSH.

lifeisstillgood 13y ago

Psh I think is a viable solution (there is a pay for / shareware package of running a shell command on a remote machine) I seem to remember doing clever things with WSI for just such a thing curiously I am pretty sure there will be examples of both on StackOverflow ;-) Edit : oh yes WMI and psexec - amazing how quickly things drop out of your brain.

KyleBrandt 13y ago

Windows has advanced in a lot of ways over the past several years. We hired Steven Murawski a little while back (Powershell MVP) and he has been able to automate just as much as would expect in the Unix world. He is also priming out infrastructure for Desired State Configuration (configuration management (like Puppet/Chef) for Windows).

pnathan 13y ago
What I'm deriving from your statement there is, "So we hired a guru to bring our Windows systems up to par with Linux base point". I'm glad its working for you, I use stackexchange daily and am generally quite happy with it!
- stevenjmurawski 13y ago
  Not at all. The Windows OS now has command line accessible management points that are similar to Linux. There is still a great deal of difference in their management models (I blogged about this a while back - http://blog.serverfault.com/2013/06/03/cross-platform-configuration-management-is-hard/ http://blog.serverfault.com/2013/06/03/cross-platform-config...) That I was hired as a Windows specialist was so that we can go deeper on the OS side and the PowerShell side, just as we have a Linux expert to go deeper on the Linux side. Our sysadmin team was just more tilted with experience on the Linux side (though you wouldn't know it - as almost everyone I work with would qualify as a senior admin in any Windows shop in the world).
  - pnathan 13y ago
    Steven, Thank you for your response. I am glad to see that there are comparable capabilities in the modern Windows world and will dig into the WMI side of things next time Windows admin tasks come up.

dvanduzer 13y ago

This kind of thing is easily handled with Kerberos. Joining Unix servers to AD doesn't require that you manage your entire Posix user database there. You can just use a Service Principal for this.

noblethrasher 13y ago

Windows supports VPN natively. * Set the firewall to only allow telnet access on a private subnet * Set the vpn connection to use that subnet * login from any computer that supports telnet and PPTP.