dlyk1988's questions

Para ter um segundo gateway "backup" para a rede da minha empresa, tentei implementar esta topologia:

É bastante simples, com a rede entre o modem e o roteador sendo a 192.168.1.0/24 e a rede entre o roteador e as estações sendo a 192.168.10.0/24. Os endereços IP reais são os do esboço.

O status das interfaces no roteador é assim:

cisco1#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.1.69    YES NVRAM  up                    up
FastEthernet0/1            192.168.10.69   YES NVRAM  up                    up
Serial0/0/0 

A tabela de roteamento é assim:

cisco1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.1.1
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, FastEthernet0/0
L        192.168.1.69/32 is directly connected, FastEthernet0/0
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/24 is directly connected, FastEthernet0/1
L        192.168.10.69/32 is directly connected, FastEthernet0/1

Como podem ver configurei o endereço IP do modem como gateway de último recurso, para que os pacotes sigam por ali em direção a Internet.

Também configurei meu PC de teste com um IP de 192.168.10.13, máscara de 255.255.255.0 e gateway padrão de 192.168.10.69.

Agora é aqui que fica estranho: na CLI do roteador, consigo executar ping com sucesso em 192.168.1.1, 192.168.1.69, 192.168.10.69 e 192.168.10.13. No PC de teste, consigo executar ping com sucesso apenas em 192.168.1.69 e 192.168.10.69. Ao tentar ping 192.168.1.1 do PC de teste, ele falha.

Claro que não tenho conectividade com a Internet do PC de teste.

Agora, há algo que estou negligenciando? Por que não consigo me conectar à internet?

ATUALIZAR:

Depois de mais algumas inspeções, minha tabela de roteamento parece realmente duvidosa. Por que as redes diretamente conectadas foram quebradas assim? Eu nunca vi os endereços IP da interface mencionados na tabela de roteamento como sub-redes "/32" separadas diretamente conectadas.

Alguém tem alguma ideia de por que isso está acontecendo? Tenho a forte sensação de que isso pode estar relacionado ao meu problema de conectividade.

Minha empresa usa a sub-rede 192.168.10.0/24 e 192.168.10.235 é, para todos os efeitos, o gateway para a Internet. Temos uma linha VDSL extra com um modem/roteador "estilo doméstico" que queremos conectar como backup. Minha ideia inicial era conectar o modem/roteador VDSL a um roteador CISCO 878 sobressalente que temos e, em seguida, conectar o 878 ao nosso switch, com um IP de 192.168.10.236, para que uma alteração do gateway padrão nas configurações do Windows seja tudo. leva para chegar à Internet através da conexão VDSL, em vez de nossa linha "empresarial" normal.

O problema é que o 878 foi feito para rotear pacotes da interface WAN (que é ISDN, então não serve para nós) para as 4 interfaces LAN e vice-versa. As interfaces LAN não são portas de roteador, mas portas de switch, todas definidas como VLAN1. Eu entendo, depois de ler a documentação oficial da CISCO, que em qualquer roteador da série 800 é impossível rotear de uma interface LAN para outra, pelos motivos mencionados acima.

Agora, eu quero perguntar isso:

Existe uma maneira de fazer isso funcionar com o equipamento que tenho?

Agora quero apresentar uma ideia sobre uma possível solução em que pensei, mas, por favor, tenha paciência comigo (é uma má ideia na melhor das hipóteses, imbecil e impraticável na pior das hipóteses):

Eu sei que posso conectar o roteador VDSL ao meu switch com o endereço IP 192.168.1.1, mesmo que todo o resto esteja na sub-rede 192.168.10.0/24. Se eu conectar o 878 no switch, com o IP 192.168.10.236 (conforme o plano original), existe uma maneira de usar uma ÚNICA de suas portas para rotear pacotes de 192.168.10.0/24 para 192.168.1.0/24 ? Minha ideia é poder mudar o gateway padrão de 192.168.10.235 para 192.168.10.236 (o endereço IP 878) e depois fazer com que o CISCO envie os pacotes DE VOLTA para o switch, mas destinados à rede 192.168.1.0/24. Lembre-se de que meu switch principal não é compatível com VLAN. Eu sei que isso provavelmente é um tiro no escuro e longe da melhor prática, mas pensei que talvez pudesse ser misturado, talvez configurando vários endereços IP na VLAN1 no 878.

Tenho 2 servidores MSSQL em execução, com mais ou menos o mesmo conjunto de dados. É realmente uma configuração de produção/desenvolvimento.

Agora, meu fluxo de trabalho é assim. Diariamente são feitos backups de cada um dos bancos de dados no servidor de produção. Transfiro os backups pela Internet (10s de Gigabytes) para o servidor de desenvolvimento. Eu "restauro" o banco de dados no servidor de desenvolvimento usando o backup do servidor de produção, para ter um conjunto de dados atual.

A minha pergunta é esta:

Existe uma maneira fácil e rápida de "exportar" uma única tabela de um banco de dados do servidor MSSQL e importá-la em um banco de dados em um servidor MSSQL diferente?

Estou mais interessado em um tipo de operação de "melhores práticas" do que em algum truque de PDV manipulado por júri.

ATUALIZAR

Depois de algumas pesquisas no Google encontrei uma função do MSSQL Server que produz um script que exporta a tabela e importa quando executado. Não posso usar isso, pois preciso importar a tabela em outro servidor.

Eu construí um contêiner a partir de um Dockerfile, baseado em uma imagem base do Archlinux. Usando um comando "RUN" instalei "cronie", já que o Arch não vem com nenhuma forma de cron. Agora, depois que o contêiner é criado, eu o executo e o anexo. Eu começo manualmente o daemon do cron, verifico se ele está realmente rodando com "ps -aux" e faço os cronjobs necessários com "crontab -e". O problema é que nenhum cronjob é executado ...

Alguma ideia?

Estou criando uma imagem do docker usando um Dockerfile bastante simples. Dentro do Dockerfile eu tenho este comando:

RUN printf "192.92.13.243 www.hahaha.com \n" >> /etc/hosts

O comando em si parece estar OK, já que a criação da imagem não para neste ponto.

O problema é o seguinte: ao executar a imagem, a linha que deveria ter sido inserida dentro de "/etc/hosts" não está lá.

Agora, pesquisei e descobri que antes da versão 1.2 do docker, havia um problema com o arquivo hosts dentro dos contêineres. No meu caso, estou usando a versão 1.5, a mais recente até o momento.

Estou esquecendo de algo?

ATUALIZAÇÃO 1:

Parece haver muitos problemas para isso, abertos e fechados, nas páginas github do docker.

Estou tentando criar uma imagem personalizada do Docker usando um Dockerfile. A imagem base que estou usando é esta:

l3iggs/archlinux

Meu Dockerfile é assim:

FROM l3iggs/archlinux:latest

COPY source /srv/visitor

WORKDIR /srv/visitor

RUN pacman -Syyu --needed --noconfirm &&
        pacman -S --needed --noconfirm cronie nodejs phantomjs &&
        printf "1.2.3.4 www.hahaha.org \n" >> /etc/hosts &&
        printf "*/2 * * * *       node /srv/visitor/visitor.js \n" >> cronJobs &&
        printf "*/5 * * * *       killall -older-than 5m phantomjs \n" >> cronJobs &&
        printf "0 0 * * * rm /srv/visitor/visitor-info.log \n" >> cronJobs &&
        crontab cronJobs &&
        rm cronJobs &&
        npm install

EXPOSE 80

CMD ["/bin/sh", "-c"]

Agora, quando chega à parte "RUN", onde deveria ser atualizado, ele trava e exibe esta mensagem de erro:

Step 3 : RUN pacman -Syyu --needed --noconfirm &&
 ---> Running in ae19ff7ca233
/bin/sh: -c: line 1: syntax error: unexpected end of file
INFO[0013] The command [/bin/sh -c pacman -Syyu --needed --noconfirm &&] returned a non-zero code: 1

Alguma ideia?

ATUALIZAÇÃO 1:

Agora, suspeito que meu problema tenha mais a ver com o comando "RUN" do que com o "pacman -Syyu" sendo executado dentro do contêiner. Isso realmente não deveria estar travando as coisas, mas claramente está.

No meu Dockerfile eu tenho a seguinte declaração 'COPY':

# Copy app code
COPY /srv/visitor /srv/visitor

Não é preciso dizer que no meu sistema host, no diretório "/srv/visitor", existe de fato meu código-fonte:

[root@V12 visitor]# ls /srv/visitor/
Dockerfile  package.json  visitor.js

Agora, quando tento construir uma imagem usando este Dockerfile, ela trava na etapa em que o "COPY" deveria acontecer:

Step 10 : COPY /srv/visitor /srv/visitor
INFO[0155] srv/visitor: no such file or directory

Ele diz que não existe tal diretório, mas claramente existe.

Alguma ideia?

ATUALIZAÇÃO 1:

Já me foi apontado que eu estava enganado, na forma como entendi construir contexto. A sugestão consistia em alterar a instrução "COPY" para isso:

COPY . /srv/visitor

O problema é que eu tinha dessa maneira, e o processo de compilação parou na próxima etapa:

RUN npm install

Ele disse algo como "nenhum arquivo package.json encontrado", quando claramente existe um.

ATUALIZAÇÃO 2:

Eu tentei executá-lo com esta alteração no Dockerfile:

COPY source /srv/visitor/

Ele parou ao tentar executar o npm:

Step 12 : RUN npm install
 ---> Running in ae5e2a993e11
npm ERR! install Couldn't read dependencies
npm ERR! Linux 3.18.5-1-ARCH
npm ERR! argv "/usr/bin/node" "/usr/sbin/npm" "install"
npm ERR! node v0.10.36
npm ERR! npm  v2.5.0
npm ERR! path /package.json
npm ERR! code ENOPACKAGEJSON
npm ERR! errno 34

npm ERR! package.json ENOENT, open '/package.json'
npm ERR! package.json This is most likely not a problem with npm itself.
npm ERR! package.json npm can't find a package.json file in your current directory.

npm ERR! Please include the following file with any support request:
npm ERR!     /npm-debug.log
INFO[0171] The command [/bin/sh -c npm install] returned a non-zero code: 34

Então, a cópia foi realizada? Se sim, por que o npm não consegue encontrar o package.json?

Estou tentando construir uma imagem do Docker a partir da imagem oficial do Arch Linux. Estas são as coisas que fiz até agora:

Eu PULL-ed a imagem oficial do Arch Linux:

docker pull base/archlinux

Eu escrevi este "Dockerfile":

# Set base image
FROM base/archlinux:latest

# Fix mirrorlist file
#RUN rm /etc/pacman.d/mirrorlist
#RUN echo "Server = http://..." >> /etc/pacman.d/mirrorlist
#RUN echo "Server = http://..." >> /etc/pacman.d/mirrorlist
#RUN echo "Server = http://..." >> /etc/pacman.d/mirrorlist
#RUN echo "Server = http://..." >> /etc/pacman.d/mirrorlist

# Update pacman and install packages
RUN pacman-db-upgrade
RUN pacman -Syyu --noconfirm
RUN pacman -S --noconfirm nodejs phantomjs cronie

# Make cronjobs
RUN echo "*/2 * * * *   node /srv/visitor/visitor.js" >> mycronjobs
RUN echo "*/5 * * * *   killall -older-than 5m phantomjs" >> mycronjobs
RUN echo "0 0 * * *     rm /srv/visitor/visitor-info.log" >> mycronjobs
RUN crontab mycronjobs
RUN rm mycronjobs

# Fix hosts file
RUN echo "192.92.13.243 www.lololol.gr"

# Copy app code
COPY . /srv/visitor

# Install app dependencies
RUN cd /srv/visitor
RUN npm install

EXPOSE 80
CMD ["/bin/bash"]

O que eu quero é que o contêiner inicie no prompt de comando, para que eu possa executar no modo interativo e anexar a ele.

Agora, recebo este erro no momento da construção da imagem:

Step 3 : RUN pacman -S --noconfirm nodejs phantomjs cronie
 ---> Running in 30870b31aed6
error: failed to initialize alpm library
(database is incorrect version: /var/lib/pacman/)
error:   try running pacman-db-upgrade
INFO[0127] The command [/bin/sh -c pacman -S --noconfirm nodejs phantomjs cronie] returned a non-zero code: 255

O que me confunde é que parece que o banco de dados do pacote foi atualizado corretamente e o sistema básico foi atualizado e ele trava ao tentar instalar três pacotes manualmente.

Alguma ideia?

Eu tenho um switch no qual 4 modems/roteadores e 2 servidores estão conectados. Cada servidor tem 2 processos em execução e 2 NICs conectados. O que eu quero é que cada processo seja roteado para fora de qualquer um dos NICs, mas com um gateway padrão diferente, para que o tráfego vá para um roteador diferente para cada processo.

ATUALIZAÇÃO 1:

Essencialmente, o que eu quero fazer é o seguinte: controlar, no nível do processo, de qual NIC o tráfego sai.

ATUALIZAÇÃO 2:

Sei que com 'Network Namespaces' posso enviar tráfego de um processo de uma NIC específica. Meu problema aqui é que ambas as NICs devem estar na mesma sub-rede. Ao mesmo tempo, o tráfego da NIC-1 deve ser direcionado para o ROUTER -1 e tráfego de NIC-2 para ROUTER-2

ATUALIZAÇÃO 3:

Estou perguntando isso de uma perspectiva do Linux.

Desejo implantar o docker em um servidor, mas quero que todos os dados relacionados ao docker estejam em uma partição separada do sistema básico. Assim, montei a referida partição em '/srv' e fiz as seguintes alterações, de acordo com a documentação oficial :

Este é o meu arquivo '/usr/lib/systemd/system/docker.service' :

[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
Type=notify
EnvironmentFile=-/srv/docker/docker.conf
ExecStart=/usr/bin/docker -d -H fd:// $OPTIONS
LimitNOFILE=1048576
LimitNPROC=1048576

[Install]
Also=docker.socket
WantedBy=multi-user.target

Este é o arquivo '/srv/docker/docker.conf' referenciado dentro do arquivo 'docker.service':

$OPTIONS="--graph /srv/docker --storage btrfs"

O daemon do docker inicia corretamente e também PULLs imagens. O problema é que ele ainda não armazena nada dentro do diretório '/srv/docker'.

Além disso, quando executo 'ps -aux | grep docker', o que recebo é isto:

root       661  0.4  0.2 351080 17044 ?        Ssl  19:33   0:00 /usr/bin/docker -d -H fd://

A linha de comando para em 'fd://'. Parece-me que '$ OPTIONS' está sendo negligenciado por um motivo ou outro.

Agora, há algum problema com a maneira como faço referência aos arquivos? Há algo mais acontecendo aqui? A razão pela qual estou fazendo todas essas alterações de configuração é que realmente gostaria de manter todos os dados relacionados ao docker no diretório '/srv/docker/'.

Alguma ideia?

ATUALIZAÇÃO 1:

Alterei meu arquivo 'docker.conf', conforme sugerido na seção de respostas. Agora:

$OPTIONS="--graph /srv/docker --storage btrfs"

passou a ser:

OPTIONS="--graph /srv/docker --storage btrfs"

Isso teve a consequência (inesperada) de o daemon do docker não iniciar. Esta é a mensagem de depuração do 'systemctl status docker':

[root@V12 ~]# systemctl status docker ● docker.service - Docker Application Container Engine Carregado: carregado (/usr/lib/systemd/system/docker.service; ativado; predefinido do fornecedor: desativado) Ativo: com falha (Resultado: sair -code) desde qui 2015-02-05 20:13:31 EET; 14s ago Docs: http://docs.docker.com Processo: 776 ExecStart=/usr/bin/docker -d -H fd:// $OPTIONS (código=exited, status=2) PID principal: 776 (código= saiu, status=2)

Este é um pouco teórico, mas por favor, tenha paciência comigo.

Atualmente tenho um servidor rodando alguns containers Docker (4 ou 5, dependendo do dia e horário). Pretendo adicionar outro, assim como o primeiro, e talvez até um terceiro.

Agora, minha pergunta é a seguinte: se chegar a hora de eu ter 15 contêineres para gerenciar, em vez de 5, há algum mérito em usar o Google Kubernetes?

Além disso, existe um fluxo de trabalho 'oficial', ou pelo menos 'definitivo', para migrar de contêineres Docker para 'pods', a unidade nativa do Kubernetes. Antes que você pergunte, sei que os pods são feitos de contêineres (às vezes até um). Meu principal problema aqui é que os 'dockerfiles' são completamente diferentes das configurações do pod.

Alguma ideia?

Peço desculpas antecipadamente se isso estiver fora do tópico.

Atualmente, estou usando Icinga e Cacti para monitorar máquinas e a rede, respectivamente. Embora não tenha grandes problemas com esta configuração, gostaria muito de ter a opção de monitorar o tráfego de rede POR PORTA em tempo real.

Existe algum utilitário que faça isso? Eu só conheço Paesler e Solar Winds, mas qualquer coisa que não seja de código aberto está fora de questão por enquanto.

Alguma ideia?

Depois de algumas tentativas e erros, consegui que o plug-in check_hwinfo funcionasse apenas parcialmente. E por parcialmente quero dizer manualmente.

No meu diretório '/usr/lib64/nagios/plugins' eu tenho o script 'check_nrpe_hwinfo.sh' com as permissões corretas:

[root@localhost plugins]# ls -lah | grep hwinfo
-rwxr-xr-x. 1 root root    419 Dec  8 15:35 check_nrpe_hwinfo.sh

No meu diretório 'conf.d' eu tenho um arquivo 'check-hwinfo.cfg' com as declarações necessárias:

define command{
        command_name    check_hwinfo
        command_line    $USER1$/check_nrpe_hwinfo.sh $HOSTNAME$ $HOSTADDRESS$
}



define service{
        use                     generic-service
        hostgroup_name          1st-floor-windows-nrpe-hosts,2nd-floor-windows-nrpe-hosts
        service_description     HW Info
        notification_options    none
        normal_check_interval   240
        notification_interval   240
        retry_check_interval    2
        max_check_attempts      120
        check_command           check_hwinfo
}

Em meus hosts do Windows, tenho o arquivo 'check_hwinfo.wsf' fornecido em 'C:\NSClient++\scripts'. Ao clicar duas vezes, o script é executado corretamente e exibe as informações em uma janela pop-up. Além disso, modifiquei o arquivo 'nsclient-full.ini' assim:

[/settings/external scripts/scripts]
check_hwinfo=c:\windows\system32\cscript.exe //NoLogo //T:30 scripts\check_hwinfo.wsf
check_hwinfo_csv=c:\windows\system32\cscript.exe //NoLogo //T:30 scripts\check_hwinfo.wsf /sep:csv

Quando no meu servidor Nagios, no diretório '/usr/lib64/nagios/plugins/' dou este comando:

./check_nrpe -H 192.168.10.13 -c check_hwinfo

Eu recebo a saída correta.

A verificação deve ser executada automaticamente. Mas... No Nagios WebUI recebo este erro na linha correspondente a check_hwinfo:

(Return code of 126 is out of bounds - plugin may not be executable) 

Depois de algumas experiências com o Nagios, acho que é apenas um erro genérico.

Então ... Alguma ideia de por que a verificação é executada e retorna corretamente quando executada manualmente, mas não quando executada automaticamente?

ATUALIZAÇÃO 1:

O arquivo 'check_nrpe_hwinfo.sh' é exatamente assim:

#!/bin/bash

ARG_HOSTNAME=${NAGIOS_HOSTNAME:-$1}
ARG_HOSTADDRESS=${NAGIOS_HOSTADDRESS:-$2}

PATH=${PATH}:/usr/lib64/nagios/plugins

HWINFO="`check_nrpe -H $ARG_HOSTNAME -c check_hwinfo_csv`"
RESULT=$?
ARG_HOSTNAME_CLEAN=`echo $ARG_HOSTNAME | tr -cd '0-9a-zA-Z._-'`

if [ "$RESULT" == 0 ]; then
        echo "\"$ARG_HOSTADDRESS\",$HWINFO" > /var/www/html/hwinfo/$ARG_HOSTNAME_CLEAN
fi
echo "$HWINFO"
exit $RESULT

ATUALIZAÇÃO 2:

[root@localhost plugins]# ./check_nrpe -H 192.168.10.13 -c check_hwinfo_csv
"Gigabyte Technology Co., Ltd.","P55A-UD3","","1","Intel(R) Core(TM) i7 CPU         870  @ 2.93GHz","2927 MHz","8192 KB","133 MHz","8192M","Non-ECC","4096M/2048M/2048M/0","932 G / 932 G","WDC WD10EALS-002BA0 ATA Device / WDC WD10EZRX-00A8LB0 ATA Device","Microsoft Windows 7 Ultimate "

Atualmente, estou gerenciando computadores distribuídos em 2 domínios AD diferentes. Chamarei os 2 domínios de MÍDIA e DADOS. Minha estação de trabalho é membro do domínio MEDIA (192.168.10/24), junto com a maioria dos meus colegas de trabalho.

O domínio DATA 10.0.62.0/24) está em um datacenter remoto. Eu tenho uma conta de administrador válida em ambos os diretórios.

Existe uma VPN instalada que me dá acesso gratuito ao domínio remoto.

Estou usando o console de gerenciamento do Windows (MMC) para gerenciar computadores em meu domínio local (MEDIA - 192.168.10.0/24). A minha pergunta é esta:

Como é possível usar o MMC da minha estação de trabalho (no domínio MEDIA) para gerenciar computadores no domínio DATA?

Eu quero usar este script Powershell para automatizar alguns backups em máquinas Win7. Quando executado manualmente a partir do terminal Powershell, o script é executado conforme anunciado e termina após alguns segundos (é um pequeno backup).

O problema é quando tento automatizar o processo com o Agendador de Tarefas. Quando chega a hora (ou quando executo a tarefa manualmente) o script é executado e executa o backup corretamente. Mas não volta para "Pronto", mesmo sabendo que acabou. Eu tenho que parar a tarefa manualmente todas as vezes.

Agora, não esperei para ver o que acontece quando chegar a hora da tarefa ser executada novamente, mas acho que não vai começar uma segunda vez, porque não está "Pronta".

O que posso fazer sobre isso?

ATUALIZAÇÃO 1:

A ação que escolhi é "Iniciar um programa". Na caixa "Programa/script" tenho "powershell.exe" e como argumento tenho o caminho para o arquivo "*.ps1" do script.

ATUALIZAÇÃO 1:

Percebi que embora a tarefa não volte para "Pronto", se eu iniciá-la manualmente, ela volta a rodar.

Estou executando o Nagios 3.5 em uma máquina Centos 7. A configuração é usada para monitorar algumas máquinas Windows via NRPE (comandos check_nrpe). Por enquanto estou usando os comandos 'alias' pré-configurados que vêm no arquivo 'nsclient-full.ini'. Tudo está funcionando bem até agora.

Desejo monitorar o estado das atualizações do Windows em meus hosts, usando o comando 'alias_updates'.

; alias_updates - Alias for alias_updates.
alias_updates = check_updates -warning 0 -critical 0 ShowAll=long

Aqui está a seção onde todos os scripts externos são definidos:

; A list of scripts available to run from the CheckExternalScripts module.
[/settings/external scripts/scripts]
check_updates=C:\Program Files\NSClient++\scripts\check_updates.vbs

É claro que verifiquei se 'check_updates.vbs' existe no caminho que forneci. Afinal, ele veio junto com o NSClient++.

Eu habilitei a execução de scripts externos:

; Check External Scripts - A simple wrapper to run external scripts and batch files.
CheckExternalScripts = 1

As outras opções de configuração relevantes (na minha opinião) são:

; Section for NRPE (NRPEServer.dll) (check_nrpe) protocol options.
[/settings/NRPE/server]

; COMMAND ARGUMENT PROCESSING
allow arguments = true

; COMMAND ALLOW NASTY META CHARS
allow nasty characters = false

; PORT NUMBER - Port to use for NRPE.
port = 5666


; Section for external scripts configuration options (CheckExternalScripts).
[/settings/external scripts]

; COMMAND ARGUMENT PROCESSING
allow arguments = true

; COMMAND ALLOW NASTY META CHARS
allow nasty characters = false

; SCRIPT DIRECTORY
script path = 

; COMMAND TIMEOUT
timeout = 60

No servidor Nagios, no prompt de comando, estou tentando o seguinte:

[root@mama365-account plugins]# ./check_nrpe -H 192.168.10.13 -c alias_updates

A resposta que estou recebendo é esta:

ExternalCommands: failed to create process (C:\Program Files\NSClient++\scripts\check_updates.vbs): it is not an exe file (check NSC.log for more info) - failed to lookup error code: 193( reson: 87)

Entendo que o NSClient pode executar plug-ins que não são executáveis ​​(*.exe), mas apenas scripts. E este é um script VB. Além disso, a mesma mensagem de erro é exibida na GUI do Nagios, na caixa correspondente ao comando.

Alguém tem alguma ideia de como consertar isso? A leitura dos documentos do NSClient++ só me trouxe até agora...

ATUALIZAÇÃO 1:

Segui as instruções fornecidas por Michael Medin ao pé da letra. Agora meu 'nsclient-full.ini' está assim:

; A list of wrappped scripts (ie. using the template mechanism)
[/settings/external scripts/wrapped scripts]
check_updates=scripts\check_updates.vbs

; VISUAL BASIC WRAPPING - 
vbs=cscript.exe //T:30 //NoLogo %SCRIPT% %ARGS%

O problema é que agora estou recebendo outro erro, desta vez algo relacionado à execução do script vb:

C:Program FilesNSClient++scriptscheck_updates.vbs(15, 1) Microsoft VBScript runtime error: Class not defined: 'NagiosPlugin' 

Por outro lado, parece que o plug-in retornou 'OK', pois a caixa correspondente no Nagios é verde.

ATUALIZAÇÃO 2:

Depois de pesquisar nos fóruns do NSClient++, encontrei alguém com o mesmo problema. Acontece que estava faltando um '\':

check_updates=scripts\check_updates.vbs

Deveria estar:

check_updates=scripts\\check_updates.vbs

Mas ainda não consigo fazer funcionar. Parece que a comunicação e a execução do script estão OK agora, mas a operação atingiu o tempo limite. Se eu substituir o tempo limite para 120s com a opção '-t' na linha de comando, recebo esta mensagem de erro:

CHECK_NRPE: Received 0 bytes from daemon.  Check the remote server logs for error messages.