Rino Bino's questions

Ao trabalhar com repositórios de pacotes deb (apt), às vezes você pode navegar por eles em http para determinar o que está disponível em diferentes arquiteturas (amd64, arm64, etc). Por exemplo, o Ubuntu fornece uma lista de arquivos para ajudar a navegar no repositório

No entanto, outras fontes, como este repositório Elastic , não permitem a navegação regular.

Minha única opção parece ser realmente adicionar o repositório às minhas fontes (fazer modificações no meu sistema):

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list

Depois de adicionar, a execução apt updateconfirma que o repositório oferece pacotes arm64 (já que estou em um host arm64):

Get:7 https://artifacts.elastic.co/packages/7.x/apt stable/main arm64 Packages [78.8 kB]

No entanto, quero confirmar TODAS as arquiteturas de lançamento disponíveis oferecidas pelo repositório E quero fazer isso sem ter que modificar meu sistema host. Como eu posso fazer isso?

Neste caso de uso, tive que ativar um host arm64 de teste apenas para determinar se os pacotes estavam disponíveis. Eu realmente gostaria de evitar ter que fazer esse tipo de coisa no futuro e apenas navegar pelas ofertas de recompra remotamente.

Estou limpando uma unidade com dd. É um dispositivo USB e 120GB e está demorando muito:

dd if=/dev/zero of=/dev/da0 bs=1M status=progress

Eu tentei mexer com o tamanho do bloco (valores menores e maiores bs=4M, bs=8Metc), mas nada parece fazer muita diferença. Está escrevendo sobre 7000 kB/so que é dolorosamente lento.

Não me importo em limpar os dados "com segurança", só quero que sejam apagados para que eu possa restabelecer a estrutura da partição e o sistema de arquivos do zero. Existe uma maneira alternativa (usando utilitários padrão) que pode executar uma limpeza rápida (dentro de um ou dois minutos) para esse tipo de cenário? O dispositivo em que estou trabalhando é o FreeBSD, mas acho que o comando dd (e gpart, etc) funciona de maneira semelhante entre ele e o Linux.

Provavelmente é mais fácil apenas mostrar por exemplo onde estou encontrando problemas, então vou direto ao ponto ...

Este snippet funcionará como está para Nginx com módulos de reescrita/autenticação ativados. Portanto, esperamos que esse problema seja rápido e fácil de reproduzir em praticamente qualquer instalação do Nginx ...

server {
  listen 8081;
  add_header x-user bar;
  return 200;
}

server {
  listen 8080;

  location = /auth {
    internal;
    proxy_pass http://localhost:8081;
  }

  location / {
    auth_request /auth;
    auth_request_set $foo $upstream_http_x_user;

    add_header x-test $foo;
    add_header success true;

    proxy_pass http://example.com/;
  }
}

O exemplo de configuração do site Nginx acima faz o seguinte:

1. Envia qualquer solicitação para /authvia auth_request chamada
2. O local /auth envia a solicitação para outro servidor que adiciona um cabeçalhox-user bar
3. auth_request_setdefine uma nova variável $foocom base no valor do cabeçalho upstream x-userdefinido na etapa 2 acima.
4. Um novo cabeçalho é definido x-testcom o valor de$foo
5. A solicitação prossegue para um destino externo.

A resposta é exatamente como eu esperaria e confirmei que o $foovar foi definido corretamente:

$ curl -s --head http://localhost:8080 | grep -E 'HTTP|x-test'
HTTP/1.1 200 OK
x-test: bar

Então, aí vem o problema...
Preciso ajustar essa configuração para que retorne 403 caso o valor do cabeçalho upstream esteja incorreto.

Parecia uma tarefa simples. Então adicionei uma if{}condicional para verificar o cabeçalho:

  location / {
    auth_request /auth;
    auth_request_set $foo $upstream_http_x_user;

    # this 'if' is the only part added to the original config
    if ($foo != bar) {
      return 403;
    }

    add_header x-test $foo;
    add_header success true;

    proxy_pass http://example.com/;
  }

A ifcondicional foi avaliada como verdadeira, então obtive um 403, que não era o que eu esperava. Então, isso não funciona :

$ curl -s --head http://localhost:8080 | grep -E 'HTTP|x-test'
HTTP/1.1 403 Forbidden

Eu percebo que se é mau, no entanto, parece que estou usando apenas para retornar , o que deve estar ok. Estou aberto a usar qualquer método para atingir o mesmo objetivo - com ou sem if , então estou aberto a ideias!!

Eu tentei fazer coisas como mover as instruções auth_requeste/ou ifpara o server{}bloco, mas nada parece fazer com que isso seja avaliado da maneira que eu esperava.

Resolução de problemas / detalhes adicionais:

Eu verifiquei que o problema é que o ifé avaliado ANTES do auth_request_seté

  location / {
    auth_request /auth;
    auth_request_set $foo $upstream_http_x_user;

    if ($foo != bar) {
      # x-test never gets set because $foo is null when if evaluates
      add_header x-test $foo always;
      add_header success false always;
      return 403;
    }

    add_header x-test $foo;
    add_header success true;

    proxy_pass http://example.com/;
  }

$ curl -s --head http://localhost:8080 | grep -E 'HTTP|x-test|success'
HTTP/1.1 403 Forbidden
success: false

Eu verifiquei que isso não é um problema se usar setem vez deauth_request_set . Isso funciona (mas não atinge o objetivo):

  # set works, but not auth_request_set
  location / {
    set $foo bar;

    if ($foo != bar) {
      return 403;
    }

    add_header x-test $foo;
    add_header success true;

    proxy_pass http://example.com/;
  }

Essa configuração funciona. seté avaliado antes if:

$ curl -s --head http://localhost:8080 | grep -E 'HTTP|x-test'
HTTP/1.1 200 OK
x-test: bar

O comportamento persiste mesmo se auth_requestestiver no server{}contexto :

server {
  listen 8081;
  add_header x-user bar;
  return 200;
}

server {
  listen 8080;

  auth_request /auth;
  auth_request_set $foo $upstream_http_x_user;

  location = /auth {
    internal;
    proxy_pass http://localhost:8081;
  }

  location / {

    if ($foo != bar) {
      return 403;
    }

    add_header x-test $foo;
    add_header success true;

    proxy_pass http://example.com/;
  }

}

$ curl -s --head http://localhost:8080 | grep -E 'HTTP|x-test|success'
HTTP/1.1 403 Forbidden
success: false

Analisei os seguintes documentos e perguntas:

• Posso comparar uma variável definida por auth_request_set depois que auth_request retornou no nginx?
• https://stackoverflow.com/questions/73431103/cant-access-added-headers-using-nginx-auth-request-set
• O cabeçalho personalizado Nginx $ upsteam_cache_status não aparecerá
• auth_request não bloqueia a diretiva de retorno, não pode retornar o status?
• https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil
• http://nginx.org/en/docs/http/ngx_http_auth_request_module.html
• http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if
• https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/

Esta questão se refere a trabalhar com um projeto Python + Poetry em um pipeline Jenkins e como manter o.venv/

CENÁRIO:

Eu tenho um trabalho do Jenkins Pipeline que aciona um projeto Python. O projeto usa poesia para criar um ambiente virtual em .venv dentro do espaço de trabalho. A cada execução de trabalho subsequente, ele reutilizará o .venv conforme o esperado, de modo que cada pacote pip não precise ser baixado novamente a cada execução (a menos que haja um diff no arquivo poet.lock). Tudo funciona como esperado.

Eu quero fazer uma alteração no Pipeline usando o Jenkins Workspace Cleanup Plugin, quero destruir os arquivos do espaço de trabalho, mas manter alguns arquivos, incluindo os arquivos de ambiente pip/poetry/venv . Isso é para permitir que ele reutilize pacotes pip da execução anterior ainda armazenados em .venv -- assim como faz no Pipeline de trabalho hoje.

O exemplo de arquivo de pipeline completo está na parte inferior deste post, mas aqui está um trecho da parte cleanWs() que adicionei ao pipeline existente:

post {
  always {
    cleanWs(
      deleteDirs: true,
      notFailBuild: true,
      patterns: [
        [pattern: '.venv', type: 'EXCLUDE'],
        [pattern: '.venv/**', type: 'EXCLUDE']
      ]
    )
  }
}

AQUI ESTÁ A QUESTÃO:

• Na primeira vez que o trabalho é executado, ele funciona perfeitamente e a limpeza do espaço de trabalho funciona conforme o esperado. O .venv/diretório é mantido conforme o esperado.

• (problema) Em execuções subsequentes do trabalho, o Poesia reinstalará todos os pacotes e não reutilizará o diretório .venv :

  Creating virtualenv test in /data/jenkins_home/workspace/test-cleanup/.venv-- Isso força um novo download completo de cada pacote, mesmo que .venvjá exista. Foi confirmado que /data/jenkins_home/workspace/test-cleanup/.venvjá existe antes da execução do trabalho.

• Aqui está a parte estranha: se eu for para o diretório do espaço de trabalho manualmente no servidor Jenkins e executar exatamente o mesmo comando poetry install , ele funcionará conforme o esperado, .venvserá reutilizado e todos os pacotes não serão reinstalados. Portanto, há algo específico sobre a maneira como ele é tratado em execução no trabalho que está fazendo com que ele queira recriar o diretório .venv.

NOTA que in-project = truejá está definido para Poesia. Portanto, ele sempre tentará usar .venv dentro do diretório de trabalho atual.

EXEMPLOS:

Aqui está um pipeline de exemplo simples que funciona conforme o esperado. Quando poetry installa etapa é executada, ela não baixa novamente todos os pacotes toda vez que o trabalho é executado, apenas na primeira vez ou se houver uma diferença:

pipeline {

  agent any

  stages {

    stage("Prep Build Environment") {
      steps {

        script {
          scmVars = git branch: "main", poll: false, url: "[email protected]:my-org/private-repo.git"
        }

        sh "poetry install"
      }
    }
  }
}

Aqui está o novo arquivo de pipeline Jenkinsfile com cleanWs()adicionado. Depois que isso for adicionado, o projeto não reutilizará mais o .venv em cada execução, mesmo que ele ainda exista:

pipeline {

  agent any

  stages {

    stage("Prep Build Environment") {
      steps {

        script {
          scmVars = git branch: "main", poll: false, url: "[email protected]:my-org/private-repo.git"
        }

        sh "poetry install"
      }
    }
  }

  post {
    always {
      cleanWs(
        deleteDirs: true,
        notFailBuild: true,
        patterns: [
          [pattern: '.venv', type: 'EXCLUDE'],
          [pattern: '.venv/**', type: 'EXCLUDE']
        ]
      )
    }
  }

}

Por favor, tome este exemplo de jogo de trabalho:

- name: Display the URL
  hosts: all
  gather_facts: false
  vars:
    - host_domain: "testing.example.com"
    - default_url: "http://def.localhost.{{ host_domain }}"
    - my_url: "{{ some_undeclared_var | default(default_url) }}"
  tasks:
    - debug:
        msg: "{{ my_url }}"

Isso funciona bem. A saída é a esperada:

msg: http://def.localhost.testing.example.com

Eu gostaria de definir o valor padrão em linha, sem primeiro declarar o default_urlvar. Algo assim:

  vars:
    - host_domain: "testing.example.com"
    - my_url: "{{ some_undeclared_var | default('http://def.localhost.{{ host_domain }}') }}"

Já tentei várias técnicas:

• my_url: "{{ some_undeclared_var | default(\'http://def.localhost.{{ host_domain }}\') }}"
• my_url: "{{ some_undeclared_var | default(\"http://def.localhost.{{ host_domain }}\") }}"
• my_url: "{{ some_undeclared_var | default('http://def.localhost.'{{ host_domain }}) }}"
• my_url: "{{ some_undeclared_var | default('http://def.localhost.'host_domain) }}"

Eu não consigo descobrir a sintaxe para isso. Alguém pode ajudar?

Estou usando netboot/pxeboot com grub.

menuentry "Install Ubuntu 20.04" {
  set gfxpayload=keep
  echo 'Loading vmlinuz ...'
  linux  /tftp/vmlinuz ip=dhcp netboot=nfs nfsroot=10.0.0.20:/data/netboot/nfs/ubuntu2004/ boot=casper toram noquiet splash=off console=tty0 console=ttyS1,57600n8 ---
  echo 'Loading initrd, this takes a long time ...'
  initrd /tftp/initrd
}

Funciona bem, no entanto, o carregamento do initrd sobre o tftp está demorando muito (mais de 30 minutos). Eu gostaria de compactar (gz/bz2) este arquivo para economizar algum tempo de transferência de arquivos.

Eu tinha visto alguns exemplos por aí referindo-se a um initrd.gz(Um exemplo: https://unix.stackexchange.com/questions/217002/which-iso-file-vmlinuz-and-initrd-gz-to-use-for-installing- centos-from-multiboo ), mas quando tentei apenas compactar o arquivo com gzip e usá-lo, recebo um erro como:

[   12.543547] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[   12.558487] Please append a correct "root=" boot option; here are the available partitions:
[   12.575161] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Existe uma maneira de compactar este arquivo para que ele possa transferir um tamanho de arquivo menor e descompactá-lo antes de tentar montar o fs raiz?

Como alternativa, existe uma maneira de transferi-lo por um protocolo diferente (HTTP/FTP/SFTP/SCP/etc)?

Estou usando a CLI do Jenkins em um script para alguma automação do Jenkins ( https://www.jenkins.io/doc/book/managing/cli/ ).

De acordo com os documentos, primeiro você precisa baixar o .jar do host Jenkins.

Atualmente estou fazendo isso executandowget http://localhost:8080/jnlpJars/jenkins-cli.jar

No entanto, gostaria de reduzir a quantidade de etapas no meu script, então gostaria de pular essa etapa de download e apenas encontrar o jenkins-cli.jardiretamente no servidor Jenkins em vez de baixá-lo primeiro.

Tentei correr find / -name "jenkins-cli.jar"sem sucesso.

Alguém sabe onde está guardado? Certamente deve existir em algum lugar, pois você pode baixá-lo diretamente do host Jenkins.

No momento, estou enfrentando um problema com a integração do Jenkins <> Github devido às alterações de autenticação do Github de hoje, depreciando a autenticação de usuário/passagem e o plug-in de origem da ramificação do Github atual.

Informações de descontinuação: https://developer.github.com/changes/2020-02-14-deprecating-password-auth/#removal

Plugin: https://github.com/jenkinsci/github-branch-source-plugin

• Jenkins: 2.249.3
• Plugin de origem da ramificação do Github 2.9.1 (mais recente)
• Esta instalação do jenkins é apenas privada (não voltada para o público)
• O repositório que está sendo acessado é privado (não voltado para o público)
• O token do Github tem acesso total ao repositório

Questão:

O plugin força a autenticação de usuário/passagem que o Github não aceita mais. As instruções indicam para colocar o TOKEN no campo de senha, mas ainda reclama depois que eu fiz isso:

A API não pode ser acessada usando autenticação de nome de usuário/senha

https://developer.github.com/changes/2020-02-14-deprecating-password-auth/#removal

As instruções indicam: "Somente credenciais de nome de usuário/senha são suportadas" e instruem a adicionar o Token no campo de senha (a captura de tela mostra isso)

A captura de tela em anexo mostra o desastre claramente:

Perguntas para ServerFault:

• Estou inserindo o token errado para as credenciais? Eu tentei:
  • um usuário nulo, com o token como a senha
  • O token como usuário e passe
  • A descrição do token como o usuário, com o token como a senha
• Normalmente, eu enviaria um problema do Github a um desenvolvedor sobre um problema de aplicativo. No entanto, como não há um componente "Problemas" para enviar problemas ao desenvolvedor do plug-in, queria fazer minha pergunta aqui, caso outros tenham atingido isso.

Fundo:

• Postgres 10.9
• O banco de dados é executado como um contêiner docker nos hosts dev. (t3.large, gp2 500 GB de armazenamento)
• O banco de dados é executado no RDS para preparação e produção. (m5.2xlarge, gp2 1TB de armazenamento)

Tudo funciona muito bem, está assim há muito tempo, e meus tempos de alteração de banco de dados parecem sempre ser mais rápidos em prod/staging versus dev (como esperado).

Problema/Pergunta:

Eu tenho uma criação de índice específica que está demorando 20x mais no RDS (que é mais poderoso) do que no host de desenvolvimento local. Em todos os outros casos que vi nos últimos dois anos, o host RDS é mais rápido porque tem mais poder de computação e velocidades de E/S mais altas.

• Dados e esquema são idênticos entre as instâncias. Usando pg_dump + pg_restore para carregar os bancos de dados dev com dados atualizados todas as noites.
• A tabela é relativamente grande (30 milhões de linhas) em comparação com outras tabelas no meu banco de dados (principalmente menos de 1 mil)

É uma operação de índice simples:

CREATE INDEX idx_email_records_created ON email_records(created_at);

Na caixa de desenvolvimento linux local:

db=> CREATE INDEX idx_email_records_created ON email_records(created_at);
CREATE INDEX
Time: 68523.557 ms (01:08.524)

No host RDS:

db=> CREATE INDEX idx_email_records_created ON email_records(created_at);
CREATE INDEX
Time: 1490902.929 ms (24:50.903)

Eu verifiquei todas as coisas normais: carga da CPU (muito livre em todos os casos), Memória (muito livre em todos os casos). Bloqueio/uso de mesa, etc.

Os hosts dev são restaurados com um novo clone do prod db todas as noites, portanto, não há discrepância no número de linhas.

Eu verifiquei max_parallel e experimentei coisas como, ALTER TABLE email_records SET (parallel_workers = ##);mas nada parece fazer diferença.

Qualquer ajuda é apreciada

Objetivo de configuração do Nginx:

• Verifique se um determinado cookie existe (não importa qual seja o valor)
• Se não existir, inclua uma importação de configuração específica.
• Eu só quero aplicar minhas regras a determinados locais, não posso aplicar essas condicionais às configurações globais do nginx. É local específico.

ATUALMENTE, a configuração se parece com isso e está funcionando bem:

  location ~ ^/somedestination\.php(/|$) {
    <... truncated other config lines for readability ...>

    include includes/xx-cache-config.conf;

    <... truncated other config lines for readability ...>

    fastcgi_pass php-fpm:9000;
  }

Este servidor tem muitos blocos de localização e cada um importtem suas próprias configurações de cache. Este é um aplicativo somente cgi, não há try_files diretos aqui.

Então, para atender aos objetivos acima, estou experimentando algo assim, verificando a existência de $cookie_uservariável e aplicando minha configuração apenas se o cooke não existir:

  location ~ ^/somedestination\.php(/|$) {

    # only include cache config if the cookie is null/empty
    if ($cookie_user = false) {
      include includes/xx-cache-config.conf;
    }

    fastcgi_pass php-fpm:9000;
  }

Parece lógico, mas aqui está o problema: eu tropecei nisso: https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

PERGUNTA: Se não devemos usar ifem um contexto de localização (de acordo com os documentos oficiais do nginx), como devo fazer isso?

EDIT: Aqui está o conteúdo do que está sendo incluído na cláusula condicional. Atualmente o nginx está SEMPRE incluindo esta configuração, meu objetivo agora é às vezes não incluí-lo (quando o cookie existe).

Nota: a própria configuração de zona está incluída em outro lugar. Essa configuração incluída permite isso.

includes/xx-cache-config.conf

fastcgi_cache CACHE_TLRS;

fastcgi_cache_bypass $no_resource_cache;

fastcgi_no_cache $no_resource_cache;

fastcgi_cache_valid 200 301 48h;
fastcgi_cache_valid 302     4h;

fastcgi_cache_revalidate on;
fastcgi_cache_use_stale http_500 http_503 timeout updating;

fastcgi_cache_lock on;
fastcgi_cache_lock_age 15s;
fastcgi_cache_lock_timeout 5s;

fastcgi_ignore_headers cache-control;

fastcgi_cache_key "$scheme$host$uri";
add_header X-Cache $upstream_cache_status;