COil's questions

Segui esta documentação , mas não consigo fazer com que minhas imagens sejam veiculadas com HTTPS.

Tenho o seguinte /etc/default/minioarquivo de configuração:

MINIO_ACCESS_KEY="admin"
MINIO_VOLUMES="/usr/local/share/minio/"
MINIO_OPTS="-C /etc/minio --address vps.ovh.net:443 --console-address :9001"
MINIO_SECRET_KEY="secret"

Se eu especificar outra porta como 9000 em vez de 443, desta vez funcionará, mas o arquivo será servido com HTTP:

http://vps.ovh.net:9000/images/product/e53b9fde-4df1-4e54-bef4-76cd8c97cdb2.jpg

Eu gerei os certificados em /etc/minio:

pwd
/etc/minio/certs
ll
rw------- 1 minio-user minio-user 1704 Feb  3 11:05 private.key
-rw-r--r-- 1 minio-user minio-user 5522 Feb  3 11:05 public.crt

Alguma idéia ou dica?

Temos dificuldade em depurar erros 400 em nosso site. Temos muitos erros como este:

10.0.0.1 - - [08/Oct/2018:14:28:07 +0200] 
"GET /les-news/palmares/detail/article/la-lettre-de-motivation-ideale-pour-une-demande-de-stage-5224/ 
HTTP/1.1" 400 131844 
"https://www.google.com/" 
"Mozilla/5.0 (Linux; Android 7.0; TECNO K7 Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36"

Um usuário relatou o problema por e-mail e foi corrigido redefinindo seus cookies em seu navegador para outros redefinir cookies não foi suficiente (mas não podemos ter certeza de que foi feito corretamente).

A plataforma é bastante complicada e tratada por um balanceador de carga F5 , dependendo do caminho que a requisição for encaminhada para diferentes servidores.

O que eu gostaria a princípio é poder reproduzir o erro porque ao acessar a URL não temos nenhuma e tudo funciona bem.

Percebemos que a maioria dos erros vem do Android/Chrome: cerca de 85% de todos os 400 erros.

Aqui está um registro completo:

timestamp   October 8th 2018, 16:26:52.000
version     1
 _id        BmQSVGYB5vF-Dw_g1gVi
 _index     f5_access-2018.10.08
 _score     - 
t _type     doc
t agent     Mozilla/5.0 (Linux; Android 8.1.0; MI 8 Build/OPM1.171019.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36
client_ip   10.0.0.1
client_port     41,068
facility    local2
host        mydomain.fr
httpversion     1
id      2,503,307,391
length      0
logsource   mydomain.network.local
message     virtual=/Common/mydomain.fr_HTTP client_ip=10.0.0.1 client_port=41068 lb_server=10.153.161.12:80 host=mydomain.fr request_port=80 username= request="GET / HTTP/1.1" server_status=400 content_length=0 resp_time=23 user_agent="Mozilla/5.0 (Linux; Android 8.1.0; MI 8 Build/OPM1.171019.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36" referer=http://mydomain.fr/article/100-millions-d-euros-sciences-po-lance-la-plus-grande-levee-de-fonds-de-son-histoire_095255b4-caef-11e8-896c-7d05c73a49da/ ID=2503307391 timestamp=2018-10-08T16:26:52+0200 pool=/Common/POOL_ETUDIANT_v2_nocache
pool        POOL_MYDOMAIN_v2_nocache
program     f5_access
referer     http://mydomain.fr/article/100-millions-d-euros-sciences-po-lance-la-plus-grande-levee-de-fonds-de-son-histoire_095255b4-caef-11e8-896c-7d05c73a49da/
request     /
request_port    80
server_ip   10.0.0.1
server_port     80
severity    Informational
status      400
stdstatus   4xx
stdvirtual  mydomain_fr_HTTP
tags        f5_access
time        23
timestamp   October 8th 2018, 16:26:52.000
type        f5_access
verb        GET
virtual     mydomain.fr_HTTP

Esta questão está relacionada com esta . Agora sabemos que os erros vêm do elasticsearch. Os problemas ainda não foram resolvidos apesar das modificações e otimizações feitas na instância es. A cada 2 horas o servidor es fica inacessível: temos timeout ou conexão redefinida por erros de peer.

Achamos que está relacionado a isso:

Eu realmente não entendo esse gráfico porque durante o dia não há indexação. O processo de indexação é iniciado apenas uma vez por dia às 2 da manhã e é executado sem problemas.

Tenho outros relatórios do Grafana, onde devo procurar?

Alguns dados:

Versões:

• pesquisa elástica: 1.7.5

Na verdade, estou usando uma RewriteMapdiretiva dentro do meu vhost para redirecionar uma lista de 800 URLs. Funciona bem tranquilo:

RewriteEngine On
RewriteMap redirects dbm=db:/data/apps/project/current/configuration/etc/httpd/conf/redirects.db
RewriteCond ${redirects:$1} !=""
RewriteRule ^(.*)$ ${redirects:$1} [redirect=permanent,last]

Eu uso um redirect.txtarquivo contendo o mapeamento. Em seguida, ele é convertido em um arquivo db:

httxt2dbm -f db -i /data/apps/project/current/configuration/etc/httpd/conf/redirects.txt -o /data/apps/project/current/configuration/etc/httpd/conf/redirects.db

Por exemplo, para este tipo de URL, está OK:

/associations/old_index.php /

Mas quando o URL contém espaços, não funciona: (suponho que será o mesmo com outros caracteres especiais)

/Universités%20direct   /

Como lidar com este caso?