ethrbunny's questions

Estou no processo de atualização de máquinas do CentOS7 -> Rocky9. Fiz algumas dezenas com sucesso, mas tive um problema com o Dell R440 mais novo.

Quando o novo sistema operacional inicializa, recebo um erro no DRAC. Um erro fatal foi detectado em um componente no barramento 2, dispositivo 0, função 0.

Tentei substituir a placa principal, mas o problema persiste.

Isso é possível? (para um sistema operacional causar um (possível) erro de hardware)?

-- editar

Consegui reproduzir isso em vários R440s

(centos 7.x)

Eu tenho configuração syslog-ng para analisar mensagens snmptrapd para que eu possa formatá-las para digestão posterior. O problema é que o syslog-ng apenas gera a mensagem n-1. IE, se houver 10 linhas no snmptrapd.log, o syslog-ng só gera 9 linhas. Se eu enviar uma nova mensagem para snmptrapd (mensagem #11), o syslog-ng produzirá a 10ª mensagem.

syslog-ng.conf:

@version:3.27
@include "scl.conf"
log {
  source {
    snmptrap(filename("/var/log/snmptrapd.log"));
  };
  destination {
    file("/var/log/syslog-ng.log");
  };
};

snmptrapd.conf:

authCommunity log,execute,net public
authCommunity log,execute,net localtrap
format2 %.4y-%.2m-%.2l %.2h:%.2j:%.2k %B [%b]:\n%v\n
outputOption s

Eu tentei adicionar uma nova linha adicional ao final do format2 , mas isso não ajuda. (snmptrapd.log obtém a linha adicional)

Eu quero usar rsyslog para capturar eventos de SANs, roteadores e afins. (Isso será encaminhado para kafka e, finalmente, elasticsearch) Até agora - isso está funcionando bem. Eu tenho isso configurado em um arquivo de configuração em /etc/rsyslog.d

O que não está funcionando é que todo o tráfego de log local (do host executando o rsyslog) também está sendo encaminhado. Eu preciso de uma maneira de enviar logs locais para endpoints locais "padrão" e logs remotos para kafka.

Isso é possível usando rsyslog?

É possível descobrir quais hosts estão usando um servidor yp? Eu quero remover/atualizar uma VM mais antiga que está agindo como um yp-server, mas não está claro quais clientes estão por aí.

Estive analisando as métricas JMX sendo exportadas do fantoche e não tenho certeza de como interpretá-las. Este em particular deveria estar medindo o compilador de pacotes, mas não está claro (para mim) o que está dizendo.

Dados de exemplo:

{
  "request": {
    "mbean": "puppetserver:name=puppetlabs.localhost.compiler.compile.develop",
    "type": "read"
  },
  "value": {
    "Mean": 515.8850223496175,
    "StdDev": 15.410435420213828,
    "75thPercentile": 533,
    "98thPercentile": 533,
    "RateUnit": "events/second",
    "95thPercentile": 533,
    "99thPercentile": 533,
    "Max": 853,
    "Count": 188,
    "FiveMinuteRate": 0.004556108829698143,
    "50thPercentile": 502,
    "MeanRate": 0.0026130935976092762,
    "Min": 386,
    "OneMinuteRate": 0.002335841296852807,
    "DurationUnit": "milliseconds",
    "999thPercentile": 533,
    "FifteenMinuteRate": 0.003374163757709876
  },
  "timestamp": 1543151404,
  "status": 200
}

Parece haver vários tipos de estatísticas misturados. A que [Taxa|Duração]Unidade corresponde? Mean / stddev parece simples .. mas o que eles estão medindo? Isso diz "515 eventos / seg" ou "515 ms / evento"? O "MeanRate" - ".002 eventos / seg ou ms/evento"?

Eu tenho um cluster k8 pré-existente ao qual desejo adicionar um nó. Parece que há um problema de versão e não tenho certeza de como resolvê-lo.

Quando tento ingressar no novo nó (usando kubeadm join):

...
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace      
configmaps "kubelet-config-1.12" is forbidden: User "system:bootstrap:rsezn8" cannot get configmaps in the namespace "kube-system"

Em um nó existente:

[root@kube0 ~]# kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.1", GitCommit:"4ed3216f3ec431b140b1d899130a69fc671678f4", GitTreeState:"clean", BuildDate:"2018-10-05T16:43:08Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
[root@kube0 ~]# rpm -qa | grep kube
kubeadm-1.12.1-2.x86_64
kubernetes-cni-0.6.0-2.x86_64
kubectl-1.12.1-2.x86_64
kubelet-1.12.1-2.x86_64

No novo nó (supostamente):

[root@kube4 ~]# rpm -qa | grep kube
kubectl-1.12.1-0.x86_64
kubelet-1.12.1-0.x86_64
kubernetes-cni-0.6.0-0.x86_64
kubeadm-1.12.1-0.x86_64

No nó mestre:

[root@kube-master kubernetes]# kubectl get configmap -n kube-system
NAME                                 DATA   AGE
coredns                              1      106d
extension-apiserver-authentication   6      106d
filebeat-config                      1      16d
filebeat-inputs                      1      16d
kube-proxy                           2      106d
kubeadm-config                       1      106d
kubelet-config-1.11                  1      106d
kubernetes-dashboard-settings        1      105d
weave-net                            0      106d
[root@kube-master kubernetes]# kubelet --version
Kubernetes v1.12.1

Quando observo as soluções anteriores para esse problema ( aqui ), parece que o novo nó é uma versão superior à existente . No meu caso, o oposto é (de alguma forma) verdadeiro. ( yum updatenão mostra nenhuma versão mais recente)

Outro problema é o kubelet-config-1.11 . Esse é o meu problema aqui? Como faço para corrigir isso?

Se você usar pdnsutil add-record , ele permitirá que entradas de DNS duplicadas sejam criadas. Existe alguma maneira de evitar isso?

Depois de muito pleitear e construir casos, meu grupo conseguiu o orçamento para comprar 4 nós e iniciar um cluster de cassandra. Cada máquina tem unidades de 3x1 TB, então estou me perguntando se é razoável ignorar a redundância de 1 via e espelhar a(s) unidade(s) de dados.

Os dados serão copiados para que isso não seja um problema.

Parece que a probabilidade de perder uma máquina em um grupo tão pequeno é muito baixa.

Isso é razoável ou estou perdendo algum problema / fator maior?

Parece que o XenServer 6.5 foi lançado e é um pouco mais rápido que o 6.2 em muitos aspectos.

Quando instalei o 6.2, aceitei os vários padrões e acabei com um sistema particionado de maneira desajeitada. A raiz é bastante pequena (e sempre ficando sem espaço), enquanto uma partição de 250 Gb fica vazia. Para tanto estou pensando em fazer uma reconstrução com a v6.5.

Eu tenho lido sobre o processo e aparentemente você não pode misturar 6.2 e 6.5 no mesmo pool. Se eu retirar os membros do pool (3) um de cada vez, reconstruí-los e colocá-los em um novo pool, posso mover as várias VMs?

EDITAR:

Para atualizar o XenServer de 6.2 para 6.5 - comece com o mestre do pool e trabalhe em cada servidor. Se você fez uma repartição, não precisa fazer as etapas de edição novamente - contanto que você selecione 'atualizar' durante a instalação do 6.5, ele não reparticionará os discos.

Tenho vários clientes Windows que desejo monitorar via nagios/nsclient. Instalei o nsclient mais recente em dois win7 x64 e um win2012 r2. Destes, um win7 funciona enquanto as outras duas máquinas retornam could not complete SSL handshakequando uma conexão é tentada a partir da máquina nagios ( libexec/check_nrpe -H hostname -c check_cpu ).

O que eu tentei:

1. verifique as senhas - todos esses sistemas têm arquivos nsclient.ini idênticos.
2. verifique as portas - nmap -P0 client_name retorna o mesmo para todos (as portas 5666 estão abertas)
3. execute o teste nscp - retorno de sistemas que não funcionam sslv3 alert: unexpected message(win7) ou failed to establish secure connection: no shared cipher(win2012)

Estou preso tentando descobrir o que há de diferente entre os sistemas Windows 7 que funcionam e os que não funcionam e tentando aplicar isso a um sistema Windows 2012.

Instalei a versão do sistema operacional recentemente (5.0.2) e estou pensando sobre este gráfico. Até o momento, tive dificuldade em encontrar uma métrica para 'capacidade de cluster' quando se trata de Cassandra. Magicamente, datastax parece ter uma resposta. Como?

Para fins de compreensão, configurei um cluster de 4 nós usando a versão mais recente/maior (lançada) do Cassandra. Os quatro nós foram ativados em sequência usando quase inteiramente as configurações padrão e parecem estar se comunicando corretamente.

Criei então um esquema da seguinte forma:

CREATE KEYSPACE first WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': '1'
};

Crie uma tabela simples com 5 colunas e adicione aproximadamente 100 mil linhas de dados. Tudo muito bem. Os dados estão disponíveis de todos os clientes, então acho que estão distribuídos uniformemente.

Então, estou procurando uma estratégia de backup e começando a mexer com instantâneos e assim por diante. Depois de executar nodetool snapshotem cada máquina, quero saber o que ela criou. Vou para a primeira máquina e procuro /var/lib/cassandra/data/first e vejo que está vazio. Hmm .. segunda máquina .. mesma coisa .. terceira .. finalmente na 4ª máquina vejo arquivos na pasta de dados e um diretório de instantâneo.

A execução nodetool ringmostra que cada sistema possui aproximadamente 25%, mas a carga é fortemente direcionada para o sistema que (parece ter) acabou com todos os dados.

Todos os dados estão realmente nesta máquina? Qual etapa eu perdi na configuração?

Estou montando um cluster cassandra de 16 nós (fator de replicação 2) e quero configurar uma programação para nodetool repair. gc_grace_seconds é o padrão.

Duas questões:

1. Meu primeiro impulso é configurar um trabalho cron para cada máquina e tentar randomizar manualmente o tempo em torno de um cronograma de uma semana. Existe uma maneira melhor?
2. Tem nodetool repairque ser executado em todos os sistemas ou em todos os # sistemas/sistemas de fator de replicação ? (IE para meus 16 nós com fator de replicação 2 - 8 sistemas - um de cada par)

Situação hipotética:

1. Configure um cluster cassandra com N nós.
2. Crie um keyspace e defina replication_factorcomo 1 e use SimpleStrategy.
3. Adicione alguns dados.
4. Remova 1 nó.

Isso significa que 1/N dos dados está faltando?

Como alguém sabe quando é hora de adicionar capacidade a um cluster cassandra? Mensagens de erro? Atuação? Algum outro sinal revelador?

Como o planejamento de capacidade com Cassandra é uma (aparentemente) arte negra, saber por onde começar e quando crescer pode ser um tanto problemático.

Tenha um pool de 3 servidores. Todos são Xen v6.2. Apliquei os últimos patches esta manhã da maneira usual:

• Mestre do pool de patches
• Mova as VMs para fora da máquina escrava 1 e reinicie-a
• Repita com o escravo 2 e depois o mestre

Isso funcionou anteriormente.

Esta manhã, o primeiro escravo não sai do modo de manutenção. Tentei várias reinicializações, 'reiniciar a pilha de ferramentas' e até removê-la do pool. A maioria relata "Não é possível encaminhar mensagens porque o servidor não pode ser contatado. O servidor pode estar desligado ou pode haver um problema de conectividade de rede."

Eu sei que este não é o caso, pois posso fazer SSH para a máquina de outro lugar na sub-rede.

Sugestões sobre onde eu errei e como corrigir isso?