Linguagem de script portátil para um administrador multi-servidor?

Question

Por favor note: portátil como em portableapps.com, não a definição tradicional. Originalmente postado em stackoverflow.com, perguntando aqui na sugestão de outro usuário.

Sou um DBA e um sysadmin, principalmente para máquinas Windows que executam o SQL Server. Eu estou procurando uma linguagem de programação / script para o Windows que não requer acesso de administrador ou um instalador, não necessitando de nenhum processo de instalação diferente de expandi-lo em uma pasta. Minha intenção é ter uma linguagem para automação na qual eu possa padronizar.

Até este ponto, tenho usado uma combinação de arquivos em lote e shell Unix, usando sh.exe de UnxUtils mas é longe de ser uma solução perfeita.

Eu avaliei um punhado de opções, todas elas têm pelo menos uma falha séria ou outra. Eu tenho uma strong preferência por algo de código aberto ou licença dupla, mas estou mais interessado em encontrar a ferramenta certa do que qualquer outra coisa. Não estou interessado em nada que dependa de Cygwin ou Java, mas neste momento eu estaria bem com algo que precisa do .NET.

Requisitos:

• Área de cobertura gerenciável (de 1 a 100 arquivos com menos de 30 MB instalados)
• Executar no Windows XP e Server (2003 +)
• Nenhum instalador (exe, msi)
• Funciona com canais, processos e arquivos externos
• Suporte para conexões MS SQL Server ou ODBC

Pontos de bônus:

• Código aberto
• FFI para chamar funções em DLLs nativas
• Suporte à GUI (nativo ou gtk, wx, fltk, etc)
• Suporte para Linux, AIX e / ou OS X
• Dinâmico, orientado a objetos e / ou funcional, interpretado ou bytecode compilado; desenvolvimento interativo
• Capaz de empacotar ou compilar scripts em executáveis

Até agora eu tentei:

• Ruby: 148 MB em disco, 23000 arquivos
• Portable Python: 54 MB em disco, 2800 arquivos
• Strawberry Perl: 123 MB em disco, 3600 arquivos
• REBOL: Ótimo, exceto código fechado e sem MSSQL ou ODBC na versão gratuita
• Squeak Smalltalk: Ótimo, exceto suporte insuficiente para scripts

---- cut: pontos de esclarecimento ----

Por que todas as limitações?
Eu percebo que alguns dos meus critérios parecem arbitrariamente limitantes. É principalmente um produto meu ambiente. Eu trabalho como um SQL Server DBA e backup Unix admin em uma divisão de uma grande empresa. Além de cerca de uma centena de caixas rodando uma ou outra versão do SQL Server no Windows, também suporto as instalações do SQL Server Express Edition em mais de mil máquinas no campo.

Devido às nossas políticas de segurança, não faço login em todas as máquinas. Frequentemente, surge um problema e recebo Admin local por algum período de tempo. Muitas vezes, é uma caixa que eu nunca toquei e ainda não tenho a configuração do meu próprio ambiente.

Eu posso ter direitos de administrador temporários na caixa, mas não sou o administrador da máquina - sou apenas o DBA. Eu não tenho interesse em pisar nos dedos dos administradores do Windows, nem quero assumir qualquer um dos seus deveres.

Se eu mencionar a "instalação" de algo, de repente se torna uma questão de interesse para o Controle de Produção e os administradores do Windows; se estou copiando um roteiro, ninguém se importa. A distinção pode não significar muito para os leitores, mas se alguém tiver a ideia errada, de repente tenho uma longa espera e uma sobrecarga significativa antes de poder instalar a ferramenta e resolver o problema.

É por isso que quero algo que possa ser copiado e executado da mesma maneira que um aplicativo portátil. E quanto à pequena pegada? Minha empresa tem três divisões, cada uma em uma localização geográfica diferente, e uma delas é uma nova aquisição. Temos diferentes políticas de controle de produção / segurança em cada divisão. Eu apoio nossos bancos de dados MSSQL em todas as três divisões. As máquinas de campo estão espalhadas pelos EUA, às vezes conectando-se à VPN através de links muito lentos. Instalar o Ruby \ usando o psexec levou muito tempo nessas conexões. Nesses casos, o maior desperdício de tempo parece ser arquivos com milhares e milhares de arquivos, em vez de seu tamanho.

Você poderia dizer que sou mimado pelo Unix, onde os administradores geralmente têm pelo menos alguma linguagem de script moderna instalada; Eu usaria o PowerShell, mas não o conheço bem e, mais importante, ele não está em todos os lugares em que preciso trabalhar.

É uma ocorrência regular que eu preciso escrever, implantar e executar algum script em curto prazo em alguma máquina em que eu nunca tenha logado. Desde que tenha Ruby ou algo parecido instalado em cada máquina que eu precisarei tocar é efetivamente impossível por causa das aprovações, do tempo e do trabalho de administração do Windows necessário. Faz mais sentido encontrar uma solução que me permita trabalhar nos meus próprios termos.

    

Answer 1

Com a capacidade de armazenamento atual, por que sua "área gerenciável" é tão pequena (e por que o número de arquivos é importante)? Minha preferência pessoal foi Perl, que só tem a desvantagem de tamanho. Na verdade, se você estiver em um único AD, poderá fazer uma instalação do ActiveState Perl em um caminho UNC e acessar esse caminho UNC de qualquer máquina, para não precisar instalar nada em todas as outras máquinas. .

Com o Perl2EXE, você pode empacotar qualquer coisa em um EXE, mas não é elegante nem eficiente em termos de tamanho.

Além disso, exceto pelo ponto desejado de compatibilidade com o Windows, o PowerShell funcionaria, exceto pelo requisito de que funcione sem um instalador. Honestamente, você pode também considerá-lo uma parte opcional do sistema operacional e apenas adicioná-lo ao seu ambiente padrão (se você tiver algum controle sobre o ambiente).

Então, essas são minhas duas sugestões.

    

Answer 2

Eu não acho que ele atenda a todos os seus requisitos (o aspecto SQL Server \ ODBC, que é claramente crítico), mas eu tenho um antigo (é data de 1996) Perlv4 exe que eu carrego em todos os lugares comigo, para sempre quer fazer algo rápido e desagradável. 379k - 1 arquivo, não precisa de instalação, roda em todos os sistemas operacionais Windows que eu tentei.

    

Answer 3

Eu diria que vbscript / jscript é sua melhor aposta para um ambiente existente em 2003. Se você pode ajustar suas especificações um pouco para permitir instalações, o PowerShell é o caminho a seguir, particularmente como o PowerShell está disponível atualmente e será usado no gerenciamento de sql. Se você realmente quer portabilidade (e, francamente, isso significa que seu potencial de script é limitado a analisar cadeias de caracteres de arquivos de texto e nomes de arquivos), então eu diria que a próxima melhor opção é o perl. O Perl não precisa de uma instalação no Windows para funcionar. Note que você não precisa de unxutils se você quer apenas comandos unix, você só precisa instalar os serviços para o subsistema unix.

Tudo o que foi dito, eu acho que sua premissa é falha. Eu não consigo pensar em uma razão que eu gostaria de "padronizar" em uma linguagem de automação, uma vez que os requisitos de tarefas para as tarefas * nix vs windows exigirão tipos de codificação muito diferentes. Por exemplo, para muitas tarefas do sistema no Windows, você usará chamadas WMI. O WMI não está disponível no * nix. (sim eu sei que o CIM é mas não é o mesmo). Mesmo as coisas simples, como caminhos de nomes de arquivos, serão analisadas e escritas de forma diferente. Eu sugeriria usar a melhor ferramenta disponível para o trabalho em questão, em vez de tentar bater a estaca inevitavelmente quadrada em um buraco redondo.

    

Answer 4

Meio irônico: Ei .. O script VB vem com o sistema operacional, quanto menor sua pegada precisa obter?

Caso contrário, eu realmente recomendo Ruby. Por que você precisa de "uma pequena pegada"? Eu coloquei Ruby em vários servidores Windows porque ele é muito prático - e não requer privilégios de administrador (embora isso em si seja uma grande bandeira vermelha quanto aos seus objetivos, mas vamos pular isso).

    

Answer 5

O que acha de AutohotKey portátil

não vá pelo nome, é muito boa linguagem geral de script de automação. Eu acredito que cobre todas as coisas que você quer.

Referência de comandos do AutoHotkey

    

Answer 6

Outro voto para o VBScript aqui; Ele pode fazer praticamente todas as suas necessidades; perde a maioria dos "pontos de bônus" embora.

    

Answer 7

Portable Python , definitivamente (eu sei que você tentou:)

    

Answer 8

Então, aqui estão meus dois centavos sobre scripts. Em sistemas de produção ... use o que há, windows 2003 - VBScript, UNIX bash / perl / python / whatever (pessoalmente eu uso um combo de bash e perl).

A possibilidade de introduzir problemas, mesmo que o intérprete reivindique 0 footprint, é enorme. Mesmo se você acabou de copiar um executável temporariamente, ele realmente deveria passar pelo gerenciamento de mudanças de qualquer maneira.

Aqui está o meu pensamento sobre isso: Eu estou lá com seus administradores - menos instalado, melhor. Além disso, se você realmente pensar muito sobre as tarefas que você está fazendo, você realmente tem um monte que precisa ser mantido em vários idiomas? Principalmente, o script é específico da tarefa e, portanto, específico do aplicativo / sistema operacional.

Eu concordo que seria legal ter um script (linguagem ing) para governá-los em todos os tipos de situação, mas acho que você descobrirá que consegue fazer muito mais usando o nativo idioma na caixa.

Além disso, se você colocar todos os seus scripts em um sistema de controle de versão, isso tornará as coisas um pouco mais fáceis para você também. Eu tenho uma pequena configuração de servidor CVS com coleções para meus scripts Powershell, VBscript, bash, perl e php.