Tim's questions

Como faço para habilitar e aplicar/obrigar a criptografia em trânsito para instâncias Oracle do AWS RDS ao configurar o banco de dados do RDS usando o CloudFormation YAML.

Eu tenho uma instância do Amazon Linux v1 em us-west-2 (Oregon) que está falhando na atualização do yum conforme abaixo. Esta é uma instância antiga que funciona bem há alguns anos, atualizada para um t3a.nano há alguns meses. Ele tem um gateway S3 na VPC.

Criei uma instância m3.large na mesma região e não tive problemas com atualizações.

Alguma ideia de como resolver isso? Não tenho suporte da AWS, então não posso perguntar a eles, mas se persistir, tentarei reproduzir novamente em uma conta que tenha suporte.

sudo yum update  amazon-ssm-agent
Loaded plugins: update-motd, upgrade-helper
Resolving Dependencies
--> Running transaction check
---> Package amazon-ssm-agent.x86_64 0:2.3.662.0-1.amzn1 will be updated
---> Package amazon-ssm-agent.x86_64 0:2.3.714.0-1.amzn1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================================================
 Package                      Arch               Version                        Repository                Size
===============================================================================================================
Updating:
 amazon-ssm-agent             x86_64             2.3.714.0-1.amzn1              amzn-updates              25 M

Transaction Summary
===============================================================================================================
Upgrade  1 Package

Total download size: 25 M
Is this ok [y/d/N]: y
Downloading packages:
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.us-east-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
To address this issue please refer to the below knowledge base article

https://access.redhat.com/solutions/69319

If above article doesn't help to resolve this issue please open a ticket with Red Hat Support.

amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.ap-northeast-2.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.ap-east-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.eu-central-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.sa-east-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.ap-southeast-2.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.us-west-2.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.us-west-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.ap-southeast-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.ap-northeast-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.
amazon-ssm-agent-2.3.714.0-1.a FAILED
http://packages.eu-west-1.amazonaws.com/2018.03/updates/5444ecdf4764/x86_64/Packages/amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64.rpm?instance_id=i-863eaf5c&region=us-west-2: [Errno 14] HTTP Error 403 - Forbidden
Trying other mirror.


Error downloading packages:
  amazon-ssm-agent-2.3.714.0-1.amzn1.x86_64: [Errno 256] No more mirrors to try.

Atualizar

Com base na sugestão de David de "yum clean all", entrei e tentei. Depois de fazer isso, o yum no diz que não há atualizações disponíveis - mesmo que o Amazon Linux me diga que há três atualizações disponíveis quando eu faço login via SSH.

Notas:

• O agente amazon-ssm atual é 2.3.662.0
• Anteriormente, o yum dizia que atualizaria de 0:2.3.662.0 para 0:2.3.714.0-1

Aqui está a sessão SSH

Last login: Thu Dec 19 09:28:01 2019 from (IP address removed)
3 package(s) needed for security, out of 8 available <-- ***
Run "sudo yum update" to apply all updates.
sudo yum clean all
Loaded plugins: update-motd, upgrade-helper
Cleaning repos: amzn-main amzn-updates epel-debuginfo epel-source
Cleaning up everything


sudo yum update -y
Loaded plugins: update-motd, upgrade-helper
amzn-main                                                | 2.1 kB     00:00
amzn-updates                                             | 2.5 kB     00:00
epel-debuginfo/x86_64/metalink                           |  17 kB     00:00
epel-debuginfo                                           | 3.0 kB     00:00
epel-source/x86_64/metalink                              |  17 kB     00:00
epel-source                                              | 4.1 kB     00:00
(1/8): amzn-main/latest/group_gz                           | 4.4 kB   00:00
(2/8): amzn-updates/latest/group_gz                        | 4.4 kB   00:00
(3/8): epel-source/x86_64/updateinfo                       | 792 kB   00:00
(4/8): amzn-updates/latest/updateinfo                      | 615 kB   00:00
(5/8): epel-source/x86_64/primary_db                       | 1.9 MB   00:00
(6/8): epel-debuginfo/x86_64/primary_db                    | 831 kB   00:00
(7/8): amzn-main/latest/primary_db                         | 4.0 MB   00:01
(8/8): amzn-updates/latest/primary_db                      | 2.5 MB   00:01
No packages marked for update

É possível impor que todas as contas em uma organização da AWS só possam criar volumes EBS criptografados?

Eu sei que você pode aplicá-lo usando funções do IAM , mas quero saber se isso pode ser feito com SCP.

Aqui está o que eu inventei até agora, mas não funciona. Anexei isso a uma conta em minha organização, mas posso criar volumes criptografados e não criptografados.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:CreateVolume",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "ec2:Encrypted": "false"
                }
            }
        }
    ]
}

Estou tentando montar um volume existente em uma nova instância do EC2 Windows usando o CloudFormation. Isso parece algo que deveria ser possível.

Visão geral

Eu tenho uma AMI fornecida pelo fornecedor que instala alguns softwares pré-configurados. Queremos criar uma única instância e alteraremos o tamanho da instância do EC2 ocasionalmente para testes de desempenho. Não queremos perder os dados no único disco do EBS que criaremos a partir da AMI.

Como estamos usando o CloudFormation, se simplesmente alterarmos a propriedade AWS::EC2::Instance.InstanceType e fizermos upload da pilha modificada, o CloudFormation criará uma nova instância e volume da AMI. Isso não é útil, pois perderemos os dados carregados do disco existente.

Método de Volumes

Eu tentei este script primeiro.

WindowsVolume:
  Type: AWS::EC2::Volume
  Properties:
    AutoEnableIO: true
    AvailabilityZone: "ap-southeast-2b"
    Encrypted: true
    Size: 30
    SnapshotId: snap-0008f111111111
    Tags:
      - Key: Name
        Value:
          Ref: AWS::StackName
    VolumeType: gp2

EC2Instance:
  Type: AWS::EC2::Instance
  InstanceType: t2.micro
  ImageId: ami-663bdc04 # Windows Server stock image
  KeyName: removed
  IamInstanceProfile: removed
  InstanceInitiatedShutdownBehavior: stop
  SecurityGroupIds:
    Fn::Split: [",", "Fn::ImportValue": StackName-ServerSecurityGroup]
  SubnetId:
    !ImportValue StackName-Subnet1
  Volumes:
    - Device: "/dev/sda1"
      VolumeId:
        Ref: WindowsVolume

recebi a mensagem de erro

Valor inválido '/dev/sda1' para unixDevice. O ponto de anexo /dev/sda1 já está em uso

Método BlockDeviceMappings

Em seguida, tentei usar BlockDeviceMappings

BlockDeviceMappings:
  - DeviceName: "/dev/sda1"
    Ebs:
      Ref: WindowsVolume

A mensagem de erro desta vez foi

Valor da propriedade Ebs deve ser um objeto

Método de anexo de volume

Eu também tentei usar um VolumeAttachment em vez da propriedade Volumes ou um BlockDeviceMapping.

VolAttach:
  Type: AWS::EC2::VolumeAttachment
  Properties:
    Device: "/dev/sda1"
    InstanceId: !Ref EC2Instance
    VolumeId: !Ref WindowsVolume

Isso me deu a mesma mensagem acima

Valor inválido '/dev/sda1' para unixDevice. O ponto de anexo /dev/sda1 já está em uso

Pergunta-chave

Alguém montou com sucesso um volume raiz existente ou um instantâneo em uma nova instância do EC2? Se for possível qual o método adequado?

Abordagens alternativas

Feliz em ouvir abordagens alternativas. Por exemplo, as opções que considerei são:

• Criando a VPC e os recursos relacionados usando o CloudFormation e, em seguida, crie a instância manualmente usando o console.
• Criando a VPC, recursos relacionados e instância do EC2 usando o CloudFormation. A partir desse ponto, pare de usar o CloudFormation e simplesmente use o console da web para alterar o tamanho da instância.

Existe uma maneira fácil de iniciar e interromper instâncias do AWS EC2 em um determinado horário todos os dias? Isso poderia me economizar muito dinheiro para meus servidores de desenvolvimento e teste.

Instalei o fail2ban usando este comando no Amazon Linux

yum install fail2ban

Meu repositório epel é definido como

mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

Eu recebi este erro quando tentei iniciar o serviço

service fail2ban start
Starting fail2ban: Traceback (most recent call last):
  File "/usr/bin/fail2ban-client", line 37, in <module>
    from fail2ban.version import version
ImportError: No module named fail2ban.version

Eu tentei essa correção neste relatório de bug usando este diff , que não é mesclado no script que tenho. Não fez diferença. Eu tentei também tentei isso , mas não tenho ideia de como isso deve funcionar, se você deve executar qualquer coisa, etc.

Alguém pode sugerir como fazer com que o fail2ban funcione no Amazon Linux?

Observe abaixo o que foi instalado com fail2ban

Instalei o AWStats 7.0 (a versão mais recente no repositório Amazon Linux) para tentar obter informações adicionais sobre o uso de largura de banda. Estou tendo problemas para fazer o AWStats analisar meus logs - suspeito que seja porque não consigo acertar o LogFormat.

Eu tentei muitas variações e eu simplesmente não consigo fazê-lo funcionar.

Aqui está o meu formato de log Nginx

log_format  main  '$remote_addr - $remote_user [$time_local] "$host" "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" "$request_time" '
                  '"$upstream_cache_status" "$sent_http_content_encoding" ';

Aqui está uma entrada de registro

1.1.1.1 - - [12/Mar/2017:07:23:53 +1300] "www.example.com" "GET /url/ HTTP/1.1" 200 7455 "https://www.google.ru/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" "46.71.136.54" "0.000" "HIT" "gzip"

Aqui está meu arquivo de configuração AWStats. Qualquer coisa que não esteja aqui é padrão e herdada do arquivo de configuração principal

# Path to you nginx vhost log file
LogFile="/var/log/nginx/pts.access.log"

# Domain of your vhost
SiteDomain="example.com"

# Directory where to store the awstats data
DirData="/var/lib/awstats/pts/"

# Other alias, basically other domain/subdomain that's the same as the domain above
HostAliases="www.example.com"

LogFormat = "%host %logname %time1 %virtualname %methodurl %code %bytesd %refererquot %uaquot %otherquot %otherquot %otherquot %otherquot"

Aqui está a saída do awstats

[root]# /usr/share/awstats/tools/awstats_updateall.pl now -awstatsprog=/usr/share/awstats/wwwroot/cgi-bin/awstats.pl
Running '"/usr/share/awstats/wwwroot/cgi-bin/awstats.pl" -update -config=example.com -configdir="/etc/awstats"' to update config example.com
Create/Update database for config "/etc/awstats/awstats.example.com.conf" by AWStats version 7.0 (build 1.971)
From data in log file "/var/log/nginx/pts.access.log"...
Phase 1 : First bypass old records, searching new record...
Searching new records from beginning of log file...
Jumped lines in file: 0
Parsed lines in file: 323
 Found 323 dropped records,
 Found 0 comments,
 Found 0 blank records,
 Found 0 corrupted records,
 Found 0 old records,
 Found 0 new qualified records.

Alguém pode identificar o que não está certo? Não consigo encontrar nenhuma informação adicional ou logs de awstats que forneçam mais informações.

Tentei atualizar meu servidor web de produção esta manhã (t2 rodando Amazon Linux), mas falhou porque fiquei sem RAM (php-fpm tinha tudo). Parei o php-fpm para liberar um pouco de RAM, mas a atualização do yum não foi concluída. O servidor está funcionando bem, mas gostaria de resolver esse problema.

# yum update
Resolving Dependencies
--> Running transaction check
---> Package glibc-headers.x86_64 0:2.17-106.168.amzn1 will be updated
--> Processing Dependency: glibc-headers = 2.17-106.168.amzn1 for package: glibc-devel-2.17-106.168.amzn1.x86_64
---> Package glibc-headers.x86_64 0:2.17-157.169.amzn1 will be an update
--> Finished Dependency Resolution
Error: Package: glibc-devel-2.17-106.168.amzn1.x86_64 (@amzn-main)
       Requires: glibc-headers = 2.17-106.168.amzn1
       Removing: glibc-headers-2.17-106.168.amzn1.x86_64 (@amzn-main)
           glibc-headers = 2.17-106.168.amzn1
       Updated By: glibc-headers-2.17-157.169.amzn1.x86_64 (amzn-updates)
           glibc-headers = 2.17-157.169.amzn1
You could try using --skip-broken to work around the problem
** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows:
glibc-devel-2.17-106.168.amzn1.x86_64 has missing requires of glibc(x86-64) = ('0', '2.17', '106.168.amzn1')
glibc-devel-2.17-157.169.amzn1.x86_64 is a duplicate with glibc-devel-2.17-106.168.amzn1.x86_64
glibc-devel-2.17-157.169.amzn1.x86_64 has missing requires of glibc-headers = ('0', '2.17', '157.169.amzn1')
glibc-headers-2.17-106.168.amzn1.x86_64 has missing requires of glibc(x86-64) = ('0', '2.17', '106.168.amzn1')
subversion-1.9.4-2.55.amzn1.x86_64 has missing requires of subversion-libs(x86-64) = ('0', '1.9.4', '2.55.amzn1')
subversion-1.9.5-1.56.amzn1.x86_64 is a duplicate with subversion-1.9.4-2.55.amzn1.x86_64

Aqui estão os pacotes glibc que estão instalados

# rpm -qa | grep glibc
glibc-devel-2.17-157.169.amzn1.x86_64
glibc-devel-2.17-106.168.amzn1.x86_64
glibc-common-2.17-157.169.amzn1.x86_64
glibc-headers-2.17-106.168.amzn1.x86_64
glibc-2.17-157.169.amzn1.x86_64

Um problema parece ser duas versões diferentes do glibc-devel instaladas. Também parece que partes do glibc estão na versão 106 e outras na versão 157.

Reiniciei o servidor, o que, como esperado, não fez diferença, mas valeu a tentativa. Eu corri o seguinte, sem efeito

yum-complete-transaction
yum-complete-transaction --cleanup-only
yum clean all

No passado, tive problemas semelhantes, mas com pacotes menos críticos. Acabei de removê-los todos e instalá-los novamente. Não acredito que isso seja possível com glibc, pois muitas coisas dependem disso.

Procurei nos fóruns do Centos e uma opção parece ser fazer o downgrade de alguns pacotes para fazer o downgrade de alguns pacotes , mas não sei se existe uma opção melhor. Como este é meu servidor de produção, gostaria de receber alguns conselhos antes de tentar isso. Se esta for uma boa abordagem, quais pacotes devo fazer o downgrade? O que eu faço depois de fazer o downgrade, uma atualização normal do yum?

Observe que tenho backups regulares e posso restaurar a partir de um backup recente, se necessário, mas prefiro não fazer isso, pois teria que refazer algum trabalho de certificado SSL que foi um pouco complicado. Pretendo migrar para o Ubuntu e usar o CloudFormation para criar o servidor no futuro, portanto, se o servidor falhar, posso simplesmente criar outro, mas essa é uma tarefa futura.

Um site tentando aumentar o desempenho que usa o CloudFlare CDN (ou qualquer CDN realmente) que já faz grampeamento OCSP deve configurar o grampeamento OCSP em sua instância do Nginx se a configuração " Full SSL " no CloudFlare for usada?

Nesta configuração, quando um navegador solicita uma página de um site protegido/em cache do CloudFlare, ele se conecta ao CloudFlare usando TLS, que então se conecta ao servidor web de origem usando TLS para recuperar a página recém-gerada. Isso significa que dois conjuntos de negociação SSL são feitos, aumentando o tempo necessário para recuperar a página. Como um aparte, HTTP/2 significa que a conexão normalmente é feita apenas uma vez por site, independentemente do número de recursos para download.

Se CloudFlare verificar o CRL para o certificado do servidor web de origem, imagino que o grampeamento do OCSP possa reduzir as verificações necessárias e, portanto, o tempo de configuração do SSL. No entanto, não sou especialista nesta área, por isso gostaria de receber opiniões sobre isso.

Algumas informações do CloudFlare sobre se é útil (o que sugere que não ajudará no desempenho)

Obrigado pela sua pergunta. No momento não fazemos verificação de revogação nos certificados atendidos pela origem. Podemos, em algum momento, no entanto, sugerir o grampeamento do OCSP se estiver usando um certificado publicamente confiável (e sem muita dificuldade).

Eu tenho um instantâneo no AWS Oregon que não posso excluir. Quando eu tento diz

Snapshot is in use by AMI ami-d2d83cxx

Verifiquei todas as regiões, não tenho nenhuma instância com esse ID. Eu costumava correr na região de Sydney, agora uso Oregon. Só tenho uma instância em execução em qualquer lugar, além de uma instância RDS.

A descrição do instantâneo é

Copied for DestinationAmi ami-d2d83xx from SourceAmi ami-55cfbbxx
for SourceSnapshot snap-3bf220xx. Task created on 1,453,573,325,838.

Quando clico no link do volume, ele vai para a página do volume, mas não há nenhum volume com esse ID.

Meu melhor palpite é que o console AWS ficou confuso. Eu criei a AMI ímpar para teste de desempenho, mas essas AMIs eram privadas e só as usei por um curto período de tempo. Também mudei coisas de Sydney para Oregon.

Como faço para excluir este instantâneo? Vai me custar dinheiro. Não muito dinheiro, mas algum.

Estou tentando usar o cache de página do Nginx em vez do cache do Wordpress. O cache parece funcionar bem, mas estou tendo problemas para definir cabeçalhos de cache condicionais com base em uma variável - se um usuário está conectado ao wordpress. Se um usuário estiver conectado, quero cabeçalhos sem cache aplicados; caso contrário, a página pode ser armazenada em cache por um dia pelo Wordpress e pelo CDN. Estou descobrindo que só posso adicionar um cabeçalho dentro de uma instrução if.

Eu li (mas não entendi totalmente, porque é tarde aqui) [se é mau] [1]. Também encontrei uma resposta na troca de pilha (no meu laptop, não consigo encontrá-la agora) que dizia que dentro de um bloco if apenas um add_header funciona.

Alguém pode me dar ideias para uma alternativa que pode funcionar melhor? Sei que posso combinar expirações com o controle de cache, mas quero mais cabeçalhos lá, além de entender e aprender.

Aqui está uma configuração significativamente simplificada com as partes relevantes no lugar.

server {
  server_name example.com;

  set $skip_cache 0;
  # POST requests and urls with a query string should always go to PHP
  if ($request_method = POST) {
    set $skip_cache 1;
  }
  if ($query_string != "") {
    set $skip_cache 1;
  }
  # Don't cache uris containing the following segments.
  if ($request_uri ~* "/wp-admin/|/admin-*|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
    set $skip_cache 1;
  }
  # Don't use the cache for logged in users or recent commenters
  if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
  }

  location / {
    try_files $uri $uri/ /blog/index.php?args;
  }

  location ~ \.(hh|php)$ {
    fastcgi_keep_conn on;
    fastcgi_intercept_errors on;
    fastcgi_pass  php;
    include  fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # Cache Stuff
    fastcgi_cache CACHE_NAME;
    fastcgi_cache_valid 200 1440m;
    add_header X-Cache $upstream_cache_status;

    fastcgi_cache_methods GET HEAD;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;

    add_header Z_ABCD "Test header";

    if ($skip_cache = 1) {
      add_header Cache-Control "private, no-cache, no-store";
      add_header CACHE_STATUS "CACHE NOT USED";
    }
    if ($skip_cache = 0) {
      add_header Cache-Control "public, s-maxage = 240";
      expires 1d;
      add_header CACHE_STATUS "USED CACHE";
    }

    add_header ANOTHER_HEADER "message";
    }
}

Li hoje que há uma vulnerabilidade significativa no OpenSSH, que foi corrigida pela versão mais recente, 7.1p2. De acordo com esta história, sua chave privada é vulnerável à divulgação.

Estou usando o Amazon Linux AMI mais recente e tudo está atualizado no repositório da Amazon.

[root@aws /]# ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1k-fips 8 Jan 2015

Aqui está a lista de quais pacotes estão disponíveis no repositório Amazon yum

yum list | grep openssh

openssh.x86_64                      6.6.1p1-22.58.amzn1            @amzn-updates
openssh-clients.x86_64              6.6.1p1-22.58.amzn1            @amzn-updates
openssh-server.x86_64               6.6.1p1-22.58.amzn1            @amzn-updates
openssh-keycat.x86_64               6.6.1p1-22.58.amzn1            amzn-updates
openssh-ldap.x86_64                 6.6.1p1-22.58.amzn1            amzn-updates

Parece que o repositório da Amazon está cerca de dois anos atrasado nas atualizações do OpenSSH. Eu li que alguns fornecedores fazem atualizações de back-port para versões mais antigas do OpenSSH, então isso pode não ser um problema, ou a Amazon pode resolvê-lo em breve.

Perguntas:

• Isto é realmente um problema?
• Se for um problema, qual é a melhor maneira de atualizar? Eu normalmente encontraria outro repositório yum, aumentaria sua prioridade e atualizaria a partir dele.

Estou com uma situação estranha com um dos meus sites, ainda em desenvolvimento na AWS. Eu tenho nginx 1.9.9 com HHVM 3.6.6-1.amzn1.x86_64 em um t2.micro. Não é acessível ao público.

Eu tenho um site escrito personalizado na raiz do domínio, tenho o Wordpress no diretório /blog e o administrador do wordpress está em /blog/wp-admin. O site personalizado tem vários arquivos, incluindo index.php. Wordpress tem index.php e todos os tipos de outras coisas no diretório do blog, wp-admin usa index.php também.

Eu posso carregar o site personalizado, ele funciona totalmente. O administrador do Wordpress funciona totalmente. A tela inicial / lista de histórias do blog Wordpress funciona totalmente. O problema é que, quando clico em qualquer um dos links do artigo do blog para visualizá-lo na íntegra, ele mostra o índice inicial do site personalizado. Então, para dizer de outra maneira

http://www.example.com/index.php  - custom website works
http://www.example.com/blog/index.php  - blog index works
http://www.example.com/blog/2015/storyname - story load doesn't work with permalink %postname% regardless of text in post name - http://www.example.com/index.php loads
http://www.example.com/blog/2015/?p=96 - story load works
http://www.example.com/blog/wp-admin/ - admin works

Quando clico no link da história, obtenho o mesmo conteúdo da página como se tivesse clicado em http://www.example.com/index.php , exceto que as imagens não carregam porque são feitas com URLs relativos

http://www.example.com/blog/2015/storyname

Quando carrego a raiz do site /index.php, recebo os seguintes cabeçalhos de depuração (veja minha configuração abaixo para saber como eles são gerados)

Z_LOCATION: PHP MAIN
URI: /index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /index.php
Z_REQUEST_FILENAME: /var/www/hr/index.php

Quando carrego /wp-admin/ recebo esses cabeçalhos de volta

Z_LOCATION: PHP MAIN
URI: /blog/wp-admin/index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /blog/wp-admin/index.php
Z_REQUEST_FILENAME: /var/www/hr/blog/wp-admin/index.php

Quando carrego o blog home /blog/index.php, recebo esses cabeçalhos de volta

Z_LOCATION: PHP MAIN
URI: /blog/index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /blog/index.php
Z_REQUEST_FILENAME: /var/www/hr/blog/index.php

Quando tento carregar este URL http://www.example.com/blog/2015/storyname , recebo os seguintes cabeçalhos de volta. Z_REQUEST_FILENAME (acima) mostra a URL errada sendo carregada.

Z_LOCATION: PHP MAIN
URI: /index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /index.php
Z_REQUEST_FILENAME: /var/www/hr/index.php

Não tenho ideia de por que ele tenta carregar o index.php raiz do site quando clico nesse URL. Pistas:

• Alterar a estrutura do permalink do Wordpress de %postname% para ?p=123 corrige o problema
• Nenhuma das outras estruturas de permalink ajuda em nada

Por que isso seria um problema apenas para visualizar os artigos do blog???? Eu me pergunto se é algo a ver com o try_files?

Não há nada no log de erros do hhvm, não há nada no log de erros do nginx. O log de acesso mostra o seguinte quando solicito o último URL

(IP removed) - - [10/Jan/2016:08:22:19 +0000] "GET /blog/2015/storyname HTTP/1.1" 200 4424 "http://www.example.com/blog/" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0" "-" "0.050"

Aqui está a configuração do meu site nginx. Não incluí o nginx.conf principal porque não acho que seja relevante. NB Eu atualizei este trabalho o código de trabalho.

server {
  server_name www.example.com;
  root /var/www/hr;
  access_log      /var/log/nginx/hr.access.log main;

  # Default location to serve
  location / {
    try_files $uri $uri/ /blog/index.php?$args;
    add_header Z_LOCATION "hr_root"; add_header URI $uri; # DEBUG
  }

  location ~*      \.(jpg|jpeg|png|gif|css|js)$ {
    log_not_found off; access_log off;
    add_header Z_LOCATION "STATIC RESOURCES REGEX"; add_header URI $uri;      # DEBUG
  }

  # Send HipHop and PHP requests to HHVM
  location ~ \.(hh|php)$ {
    fastcgi_keep_conn on;
    fastcgi_intercept_errors on;
    fastcgi_pass       php;
    include                        fastcgi_params;
    fastcgi_param      SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # DEBUGGING
    add_header Z_LOCATION "PHP MAIN"; add_header URI $uri;
    add_header Z_DOCUMENT_ROOT "$document_root"; add_header Z_FASTCGI_SCRIPT_NAME "$fastcgi_script_name";
    add_header Z_REQUEST_FILENAME "$request_filename";
  }
}

# Forward non-www requests to www
server {
  listen 0;
  server_name example.com;
  return 302 http://www.example.com$request_uri;
}

Quaisquer pensamentos, ideias ou ajuda são apreciados. Este é bastante encaracolado, para mim, mas suspeito que será uma mudança simples para corrigi-lo.