All perguntas(server)

Considere o seguinte ambiente de cluster VMware:

1 x chassi de servidor blade Cisco UCS 5108

6 x Cisco UCS B200 M3 (vSphere 6.5 Enterprise Plus)

1x VMware vCenter Standard 6.5

Tivemos um problema com um dos servidores, provavelmente causado por um HBA de armazenamento com defeito. Infelizmente, no momento do incidente, a VM do vCenter estava hospedada no servidor com defeito. Passamos por todos os tipos de problemas para mover manualmente todas as VMs para os outros servidores e, no final, tudo deu certo, exceto a VM do vCenter. Suspeitamos que algo nele tenha sido corrompido porque não conseguimos executar alguns serviços, especialmente o serviço vmware-sps, que causou alguns problemas com backups da Veeam e outras funcionalidades. Ao tentar iniciar manualmente o serviço vmware-sps, obtivemos o seguinte:

Command> service-control --all --status
Running:
 applmgmt lwsmd pschealth vmafdd vmcad vmcam vmdird vmdnsd vmonapi vmware-cis-license vmware-cm vmware-content-library vmware-eam vmware-mbcs vmware-perfcharts vmware-psc-client vmware-rhttpproxy vmware-sca vmware-statsmonitor vmware-sts-idmd vmware-stsd vmware-updatemgr vmware-vapi-endpoint vmware-vmon vmware-vpostgres vmware-vpxd vmware-vpxd-svcs vmware-vsan-health vmware-vsm vsphere-client vsphere-ui
Stopped:
 vmware-imagebuilder vmware-netdumper vmware-rbd-watchdog vmware-sps vmware-vcha

Command> service-control --start vmware-sps
Perform start operation. vmon_profile=None, svc_names=['vmware-sps'], include_coreossvcs=False, include_leafossvcs=False
2024-08-07T12:21:32.331Z   Service sps state STOPPED
Error executing start on service sps. Details {
    "resolution": null,
    "detail": [
        {
            "args": [
                "sps"
            ],
            "id": "install.ciscommon.service.failstart",
            "localized": "An error occurred while starting service 'sps'",
            "translatable": "An error occurred while starting service '%(0)s'"
        }
    ],
    "componentKey": null,
    "problemId": null
}
Service-control failed. Error {
    "resolution": null,
    "detail": [
        {
            "args": [
                "sps"
            ],
            "id": "install.ciscommon.service.failstart",
            "localized": "An error occurred while starting service 'sps'",
            "translatable": "An error occurred while starting service '%(0)s'"
        }
    ],
    "componentKey": null,
    "problemId": null
}

/var/log/vmware/vmware-sps/sps.log

2024-08-07T09:21:36.969-03:00 [main] ERROR opId=sps-Main-33292-112 com.vmware.sps.StorageMain - Exception when running SPS service
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'httpServerEndpoint' defined in class path resource [../conf/pbm-spring-config.xml]: Could not resolve placeholder 'pbm.http.port' in value "${pbm.http.port}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'pbm.http.port' in value "${pbm.http.port}"
        at org.springframework.beans.factory.config.PlaceholderConfigurerSupport.doProcessProperties(PlaceholderConfigurerSupport.java:223)
        at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:222)
        at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:86)
        at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:281)
        at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:161)
        at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:687)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:525)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:105)
        at com.vmware.vim.storage.common.app.CommonSpringService.createSpringAppContext(CommonSpringService.java:38)
        at com.vmware.pbm.app.PbmLocalService.initialize(PbmLocalService.java:135)
        at com.vmware.pbm.app.PbmLocalService.<init>(PbmLocalService.java:117)
        at com.vmware.pbm.app.PbmLocalService.initInstance(PbmLocalService.java:195)
        at com.vmware.sps.StorageMain.loadPbmService(StorageMain.java:169)
        at com.vmware.sps.StorageMain.main(StorageMain.java:38)
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'pbm.http.port' in value "${pbm.http.port}"
        at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174)
        at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126)
        at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer$PlaceholderResolvingStringValueResolver.resolveStringValue(PropertyPlaceholderConfigurer.java:258)
        at org.springframework.beans.factory.config.BeanDefinitionVisitor.resolveStringValue(BeanDefinitionVisitor.java:282)
        at org.springframework.beans.factory.config.BeanDefinitionVisitor.resolveValue(BeanDefinitionVisitor.java:204)
        at org.springframework.beans.factory.config.BeanDefinitionVisitor.visitGenericArgumentValues(BeanDefinitionVisitor.java:159)
        at org.springframework.beans.factory.config.BeanDefinitionVisitor.visitBeanDefinition(BeanDefinitionVisitor.java:85)
        at org.springframework.beans.factory.config.PlaceholderConfigurerSupport.doProcessProperties(PlaceholderConfigurerSupport.java:220)
        ... 14 more

Nossas pesquisas no Google e na documentação oficial não tiveram sucesso. Não temos um contrato de suporte VMware ativo (eu sei, eu sei, mas não é minha culpa...). Alguém tem uma idéia de como solucionar e reparar isso? Desde já, obrigado!

27.x

Quando tentei examinar os logs de um pod, obtive: Falha ao carregar logs: Get "https://...?tailLines=502×tamps=true": erro remoto: tls: erro interno Motivo: indefinido (500)

Quando olho os certificados usando o kubeadm, eles parecem válidos até o próximo ano e eu os atualizei em janeiro.

Quando olho para kubectl get csr -AI tenho centenas de csrs pendentes.

Atualizei do SLES 15 SP5 para o SLES 15 SP6.
Cada atualização do SP causa problemas com o Apache/PHP. Agora de novo.
O problema atual é que quando o nãoindex.php é especificado, o arquivo é baixado. Especificar o script PHP na URL executa o código PHP.

sub.foo.com/--> baixa o index.php
sub.foo.com/index.php--> executa corretamente oindex.php

Isso significa que o Apache e o PHP funcionam corretamente, mas de alguma forma não ativam o manipulador PHP quando NÃOindex.php é especificado.

No arquivo de log do Apache há esta entrada:
"GET / HTTP/1.1" 200 2537

httpd.conftem esta diretiva:
DirectoryIndex index.php index.html index.html.var

Não há .htaccessarquivo.

Antes da atualização, tudo estava funcionando corretamente. A atualização deve ter modificado algo e, desde então, estou com esse problema.

PHP 8.3.9
:

Server version: Apache/2.4.58 (Linux/SUSE)  
Server built:   2024-07-17 04:55:34.000000000 +0000

Como faço para copiar uma Tarefa de Fluxo de Dados (DFT) completa de um projeto para outro se colar o gerenciador de conexões do projeto gera o erro:

Pelo menos um gerenciador de conexão não pôde ser colado corretamente.

O gerenciador de conexões com o nome 'MyConnMngr' não pôde ser colado com sucesso.

O gerenciador de conexões não pôde ser criado.

Referência de objeto não definida para uma instância de um objeto.

(Microsoft.DataTransformationServices.Design)

Aqui está a cópia completa da mensagem. O link está inativo:

TITLE: Microsoft Visual Studio
------------------------------

The designer could not paste one or more connection managers.

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%C2%AE%20Visual%20Studio%C2%AE&ProdVer=15.9.28307.2094&EvtSrc=Microsoft.DataTransformationServices.Design.SR&EvtID=PasteComponentsFailureCause_couldNotRestoreConnectionManagers&LinkId=20476

------------------------------
ADDITIONAL INFORMATION:

At least one connection manager could not be pasted correctly.
The connection manager with the name 'MyConnMngr' could not be pasted successfully.
The connection manager could not be created.
Object reference not set to an instance of an object. (Microsoft.DataTransformationServices.Design)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%C2%AE%20Visual%20Studio%C2%AE&ProdVer=15.9.28307.2094&EvtSrc=Microsoft.DataTransformationServices.Design.SR&EvtID=RestoreConnectionManagers_AtLeastOneRestoreConnectionManagerErrorOccured&LinkId=20476

------------------------------
BUTTONS:

OK
------------------------------

Se fosse apenas esse gerenciador de conexão que eu teria que construir do zero novamente, eu não perderia tempo com essa pergunta. Mas esse erro impede a colagem de todo o DFT, e eu não consigo nem copiar e colar nenhuma caixa passo a passo.

A única coisa que foi colada de todo o DFT foi um Flat File Connection Manager para o pacote. Parece que os gerenciadores de conexão para o projeto não podem ser colados. Eu tentei em dois projetos. Eu sei que às vezes os objetos ainda são arquivos no projeto e não são mostrados no explorador de projetos. Esses arquivos podem bloquear a colagem de novos objetos com o mesmo nome, ou você receberia um aviso para substituí-lo pelo menos. Portanto, colei o DFT em um projeto que não tinha nenhum gerenciador de conexão com esse nome ou função antes, e ainda assim, o erro apareceu.

Trabalho em uma versão mais antiga do SSIS, de 2016. Talvez uma versão mais nova consiga lidar com isso, mas duvido.

Depois que vários sites em um host foram hackeados ao mesmo tempo, comecei a pesquisar alguns anos atrás e li em algumas perguntas do SF uma solução para o meu problema: pools PHP-FPM

Basicamente, esta foi a estrutura que projetei depois disto:

E por muito tempo eu me senti muito confiante de que tudo estava muito mais seguro do que antes, porque se um site fosse hackeado de alguma forma, isso nunca afetaria os outros sites no mesmo host.

Mas alguns meses atrás, comecei a falar com alguns caras do docker, e eles me disseram que eu deveria começar a experimentar com contêineres e migrar minha solução para um sistema dockerizado completo. Eles me sugeriram usar o Caddy. Mas depois de ler a documentação do Caddy, notei que a nova estrutura se parece com isso:

Basicamente, o que posso ver é que o servidor Caddy tem acesso irrestrito total a todos os arquivos. Diferentemente do Nginx anterior, em que tudo parecia compartimentado, aqui parece que se houver um problema de segurança no servidor Caddy, tudo pode ser comprometido.

Eu entendo que na maioria das vezes, a maioria dos hacks vem de erros de codificação nos pontos finais, o que significa que os elos mais fracos são os servidores docker FPM que são compartimentados. Mas se o Caddy for comprometido, ele vazará informações completas de todos os volumes

Neste ponto, tenho duas perguntas:

1. Já que muitas pessoas estão defendendo que o Docker é uma das opções mais seguras, estou esquecendo de algo? Sinto que isso é um pouco menos seguro do que meu sistema anterior (embora seja verdade que se todo o sistema de arquivos em um único host for comprometido, então não importa se há uma limitação de permissão de arquivo no host, então, nesse aspecto, é verdade que o Docker é mais seguro)

2. Há alguma outra prática para tornar a configuração Docker/Caddy/FPM mais segura da perspectiva de acesso a arquivos/PHP-software-dia-zero além de manter o sistema atualizado? Atualmente, tenho sockets de arquivo entre Caddy e FPM, mas sinto que ter todos os arquivos em apenas um host expõe muito o todo.

Em um cluster Kubernetes 1.25 com 2 controladores Ubuntu, após detectar a expiração de certificados dentro de /etc/kubernetes/pki, lançamos o comando 'kubeadm promote all' em ambos os nós controladores e reinicializamos os nós.

Após a reinicialização, o kube-apiserver não consegue mais inicializar e seu contêiner docker continua travando.

Os logs do docker reclamam de não alcançar o servidor oidc (é um pod keycloak), então parece que o conector oidc é obrigatório para iniciar o servidor api:

{"log":"I0805 13:24:51.011009       1 plugins.go:158] Loaded 12 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,NodeRestriction,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection,RuntimeClass,DefaultIngressClass,MutatingAdmissionWebhook.\n","stream":"stderr","time":"2024-08-05T13:24:51.011063776Z"}
{"log":"I0805 13:24:51.011027       1 plugins.go:161] Loaded 11 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,PodSecurity,Priority,PersistentVolumeClaimResize,RuntimeClass,CertificateApproval,CertificateSigning,CertificateSubjectRestriction,ValidatingAdmissionWebhook,ResourceQuota.\n","stream":"stderr","time":"2024-08-05T13:24:51.011072396Z"}
{"log":"I0805 13:24:51.013060       1 etcd.go:292] \"Using watch cache\" resource=\"customresourcedefinitions.apiextensions.k8s.io\"\n","stream":"stderr","time":"2024-08-05T13:24:51.013133647Z"}
{"log":"E0805 13:25:01.010261       1 oidc.go:335] oidc authenticator: initializing plugin: Get \"https://10.10.2.123/admin/master/console/#/MYORGANIZATION/.well-known/openid-configuration\": dial tcp 10.10.2.123:443: connect: connection refused\n","stream":"stderr","time":"2024-08-05T13:25:01.010450438Z"}
{"log":"E0805 13:25:11.009612       1 oidc.go:335] oidc authenticator: initializing plugin: Get \"https://10.10.2.123/admin/master/console/#/MYORGANIZATION/.well-known/openid-configuration\": dial tcp 10.10.2.123:443: connect: connection refused\n","stream":"stderr","time":"2024-08-05T13:25:11.009785705Z"}

Os logs do kubelet dizem que o kubelet não consegue encontrar o primeiro nó do kubernetes (esperado porque o kube-apiserver não está funcionando):

Aug 05 16:33:21 mynode1hostname kubelet[3556]: E0805 16:33:21.973266    3556 kubelet.go:2448] "Error getting node" err="node \"mynode1hostname\" not found"
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.032233    3556 controller.go:144] failed to ensure lease exists, will retry in 7s, error: Get "https://10.10.2.123:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/mynode1hostname?timeout=10s": dial tcp 10.10.2.123:6443: connect: connection refused
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.074320    3556 kubelet.go:2448] "Error getting node" err="node \"mynode1hostname\" not found"
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.083596    3556 file.go:182] "Provided manifest path is a directory, not recursing into manifest path" path="/etc/kubernetes/manifests/BACKUP"
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.174820    3556 kubelet.go:2448] "Error getting node" err="node \"mynode1hostname\" not found"

O arquivo kube-apiserver.yaml é bastante padrão. Tentamos remover a dependência do OIDC comentando suas linhas sem sucesso, pois o kubelet ainda reclama por não alcançar o OIDC (então o OIDC parece um loop morto circular, pois o kubelet não pode iniciar sem oidc e o pod keycloak não pode iniciar devido ao kubelet falhar e assim por diante):

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.10.2.123:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.10.2.123
    - --anynomous-auth=true
    - --allow-privileged=true
    - --audit-log-path=/var/log/kube-apiserver.log
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --token-auth-file=/etc/kubernetes/passwords.csv
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
      #    - --oidc-issuer-url=https://10.10.2.123/admin/master/console/#/MYORGANIZATION
      #    - --oidc-client-id=Kubernetes
      #    - --oidc-username-claim=username
      #    - --oidc-groups-claim=group
    - -v=5
    image: registry.k8s.io/kube-apiserver:v1.25.11
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 10.10.2.123
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver
    readinessProbe:
      failureThreshold: 3
      httpGet:
        host: 10.10.2.123
        path: /readyz
        port: 6443
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:
      requests:
        cpu: 250m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 10.10.2.123
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/ca-certificates
      name: etc-ca-certificates
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
    - mountPath: /usr/local/share/ca-certificates
      name: usr-local-share-ca-certificates
      readOnly: true
    - mountPath: /usr/share/ca-certificates
      name: usr-share-ca-certificates
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/ca-certificates
      type: DirectoryOrCreate
    name: etc-ca-certificates
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /usr/local/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-local-share-ca-certificates
  - hostPath:
      path: /usr/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-share-ca-certificates
status: {}

Alguém também encontrou um caso semelhante após renovar os certificados do Kubernetes e reiniciar os nós? Tentei pesquisar no SO sem nenhuma evidência clara deste caso.

Agradeço antecipadamente

Estou enfrentando um problema com nosso e-mail do servidor. Ontem, nosso provedor de e-mail ficou fora do ar por mais de 20 horas, impactando gravemente nossas operações comerciais.

Temos aproximadamente 5 TB de e-mails arquivados, que os usuários pesquisam frequentemente em busca de contratos anteriores ou outras informações. Apesar do grande volume, eles fazem questão de guardar todos os emails. A configuração atual está usando postfix/dovecot, usando o formato mdbox.

Recebi a tarefa de melhorar a confiabilidade e o desempenho do servidor. Minhas soluções propostas são:

1. Separe e-mails novos e antigos: mova e-mails antigos para um armazenamento separado, reduzindo a carga de sincronização no servidor primário.

2. Implemente alta disponibilidade: adicione um novo servidor de email em um local diferente. Se um servidor falhar, o outro deverá assumir e sincronizar os dados após a recuperação do primeiro servidor.

3. Apresente um proxy de e-mail: filtre os e-mails recebidos e encaminhe-os para ambos os servidores para redundância.

4. Aproveite o Amazon S3 para backup: Utilize o bucket S3 existente para armazenar e-mails antigos, alinhando-se com o plano de separação de datas.

Estou pensando em usar o mdbox e o rsync existentes para essas tarefas, porque atualmente estamos usando o mdbox para armazenamento de e-mail e o rsync para fazer backup de todos os arquivos de e-mail e outros arquivos para o armazenamento em nuvem. Então, estou tentando usar os métodos existentes. Mas ainda tenho algumas perguntas:

1. O rsync simples é suficiente para sincronizar arquivos de email? Poderia criar entradas duplicadas se as mensagens chegassem em momentos diferentes através do proxy?

2. Como posso separar efetivamente o armazenamento de e-mail por ano usando o mdbox?

3. Existe uma ferramenta mais eficiente para configurar a replicação Dovecot entre dois servidores de e-mail idênticos?

Não entrei em contato com a tecnologia de correio e agradeceria qualquer recomendação ou informação que você possa fornecer.

Obrigado

Na minha configuração do nginx, estou adicionando alguns cabeçalhos http globalmente na seção http. No entanto, um cabeçalho específico depende de um valor que só conheço após mapear o bloco de localização.

Quando adiciono a add_headerdiretiva no bloco location, todos os cabeçalhos da seção http precisam ser listados novamente, pois não serão herdados. Isso é conforme pretendido, conforme indicado nos documentos :

Estas diretivas são herdadas do nível de configuração anterior se e somente se não houver diretivas add_header definidas no nível atual.

Para contornar isso, tentei definir o cabeçalho na seção http com um valor de variável e usei um mapa para inicializar a variável (como setnão é permitido no httpnível, veja a documentação ). Eu então seta variável para outro valor dentro do locationbloco:

http {
    map "" $my_header {
        default "A";
    }

    add_header X-My-Header $my_header;

    # ...

    server {
        # ...
        location /myLocation {
            set $my_header "B";
            # ...
        }
    }
}

Isso, porém, não funcionará – X-My-Headersempre terá o valor A.

Existe alguma maneira de fazer isso (sem usar add_headerdiretamente locatione, portanto, a necessidade de repetir ou includetodos os outros cabeçalhos httptambém)?

E, apenas por razões educativas, porque é que a minha tentativa não está a funcionar como esperado?

Pergunta

Existe uma regra geral sobre se a inserção de hardware conectado ao PCIe (e não a remoção) de uma placa-mãe em execução (ou apenas alimentada, se relevante) pode ser perigosa para o hardware, especialmente para a placa-mãe? Já vi uma infinidade de perguntas sobre remoção, mas não adição.

Se não houver uma regra geral, estou procurando uma certificação específica ou capacidade nomeada no hardware e/ou placa-mãe a ser conectado?

Justificativa

Estou avaliando um bug com uma NIC PCIe - um TP-LINK AXE5400 que causa BSoD no Windows 11 se conectado durante a instalação do sistema operacional via USB - o que envolve uma quantidade significativa de conexão e desconexão. Costumo desabilitar o UEFI Fast Boot para garantir e não quero ter que reativá-lo e desligá-lo e reinicializá-lo manualmente sempre que quiser avaliá-lo (des/re-)conectado.

(Falta de) duplicatas

1. Isso é o oposto de Posso retirar uma placa do barramento PCI-x sem desligar?

   Eu acidentalmente esqueci de desconectar a energia de um servidor ao puxar uma placa, mesmo que o sistema estivesse desligado no nível do sistema operacional.

   Infelizmente, isso parece ter corrompido o BIOS do sistema e o BIOS IPMI/BMC. Também parece ter frito o vídeo on-board.

   Isso ocorreu em uma placa-mãe Supermicro e é por isso que tentei atualizar novamente o BIOS principal e o BIOS IPMI. A atualização do BIOS principal ocorreu sem problemas e nenhum erro é mostrado em nenhum registro do BIOS.

   Achei que a tecnologia hotplug deveria significar que eu poderia puxar fisicamente uma placa enquanto ela estava em execução. Pesquisas na internet parecem implicar isso.

   ... porque posso imaginar que a árvore de dispositivos seria afetada de forma significativamente menos problemática se ocorresse uma adição, já que não é como remover uma GPU durante a operação (o que causaria todos os tipos de problemas previsíveis).

2. https://serverfault.com/search?q=insert+pcie+running+machine retornou 0 resultados (em 05/08/2024).

temos alguns servidores red-hat com os seguintes detalhes (quando o tamanho do disco do sistema operacional é 230G)

# lsblk
NAME             MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                8:0    0  230G  0 disk
├─sda1             8:1    0    1G  0 part /boot/efi
├─sda2             8:2    0    1G  0 part /boot
└─sda3             8:3    0  228G  0 part
  ├─VG100-lv_root 253:0    0   20G  0 lvm  /
  ├─VG100-lv_swap 253:1    0   16G  0 lvm  [SWAP]
  └─VG100-lv_var  253:2    0   30G  0 lvm  /var


fdisk -l

Disk /dev/sda: 193.3 GB, 193273528320 bytes, 377487360 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   209715199   104857599+  ee  GPT

o objetivo é aumentar o /var e o sistema de arquivos raiz com base no tamanho do disco é 230G quando o /var atual é 30G e o sistema de arquivos raiz é 20G

então, começamos com o seguinte procedimento que deve nos fornecer PFREE suficiente ou espaço “Físico Livre” suficiente.

parted /dev/sda resizepart 3 100%
Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)?
parted: invalid token: 3
Fix/Ignore/Cancel?


sgdisk -e /dev/sda

nota - sgdisk: A maneira mais simples de corrigir a tabela GPT de backup é usando o comando sgdisk com a opção -e, que move as estruturas de dados GPT de backup para o final do disco

parted /dev/sda resizepart 3 100%
Information: You may need to update /etc/fstab.

partprobe /dev/sda

pvresize /dev/sda
  Failed to find physical volume "/dev/sda".
  0 physical volume(s) resized or updated / 0 physical volume(s) not resized

mas de pvs Pfreeainda é 0

# pvs
  PV         VG   Fmt  Attr PSize  PFree
  /dev/sda3  VG100 lvm2 a--  66.00g    0

alguma idéia sobre outra abordagem capaz de aumentar as partições do sistema de arquivos /var e raiz?

mais informações

# vgs
  VG   #PV #LV #SN Attr   VSize    VFree
  VG100  1   3   0 wz--n- <228.00g <162.00g

nós também tentamos isso (por exemplo)

lvextend -l +100%FREE -r /dev/mapper/VG100-lv_root
  Size of logical volume VG100/lv_root unchanged from 20.00 GiB (5120 extents).
  Logical volume VG100/lv_root successfully resized.

xfs_growfs /dev/mapper/VG100-lv_root

mas o tamanho do sistema de arquivos raiz é o mesmo

df -h | grep VG100-lv_root
/dev/mapper/VG100-lv_root   20G  3.8G   17G  19% /

 pvs
  PV         VG   Fmt  Attr PSize  PFree
  /dev/sda3  VG100 lvm2 a--  66.00g    0