Forem: Marks Duarte

[Boost]

Marks Duarte — Sun, 20 Apr 2025 12:08:31 +0000

Hugo Marques

Apr 15 '25

parallelStream() Aninhado: Mais Concorrência, Menos Performance

#java #performance #concurrency #braziliandevs

Comments 5

3 min read

ASSINANDO COMMITS NO WINDOWS E PUBLICANDO NO GITHUB

Marks Duarte — Wed, 21 Feb 2024 02:57:48 +0000

Como segurança nunca é demais, vamos aprender como assinar nossos commits usando chaves GPG para garantir a integridade e confiabilidade do autor.

Instalando GPG no Windows

Para facilitar a criação das nossas chaves, podemos instalar um cli chamado gnupg.

https://www.gnupg.org/download/

Gerando uma nova chave GPG

O GitHub, GitLab e Azure Devops suportam vários formatos de chaves, tais como:

RSA
ElGamal
DSA
ECDH
ECDSA
EdDSA

Feita a instalação do gnupg na versão 2.1.17+, execute o comando:

gpg --full-generate-key

Especifique qual tipo de chave deseja gerar, seu tamanho e o tempo de validade, nome de usuário, e-mail e senha de criptografia.

Atente-se ao fato de que o e-mail informado deve ser o mesmo utilizado no GitHub e etc.

Liste as chaves armazenadas e copie o ID da chave que desejada:
O ID é o código 3AA5C34371567BD2, como no exemplo abaixo.

gpg --list-secret-keys --keyid-format=long

$ gpg --list-secret-keys --keyid-format=long
/Users/marks/.gnupg/secring.gpg
------------------------------------
sec   4096R/3AA5C34371567BD2 2024-02-20 [expires: 2024-03-20]
uid                          Marks <marks@example.com>
ssb   4096R/4BB6D45482678BE3 2024-02-20

Passe o ID copiado como parâmetro do comando que imprime a chave pública que deverá ser informada no GitHub:

gpg --armor --export 3AA5C34371567BD2
# Imprime a chave GPG em formato ASCII

Copie todo o texto começando com

-----BEGIN PGP PUBLIC KEY BLOCK-----

e terminando com

----END PGP PUBLIC KEY BLOCK-----.

Agora acesse sua conta no github, vá até configurações > SSH and GPG keys e adicione a chave ASCII gerada.

Configurando o GIT

Antes de configurar o git, vamos garantir que não exista um formato de assinatura previamente informado.

git config --global --unset gpg.format

Agora podemos configurá-lo para assinar nossos commits de forma global ou local:

git config --global user.signingkey 3AA5C34371567BD2
git config --local user.signingkey 3AA5C34371567BD2

Lembre-se de copiar o ID da chave ou listar novamente com gpg --list-secret-keys --keyid-format=long

Agora faça um commit assinado com o comando:

git commit -S -m "message"

Opcionalmente, podemos configurar o Git para assinar todos os commits por padrão, com o comando: git config --global commit.gpgsign true

Caso ocorra o erro signing failed: No secret key, informe para o git o path do gpg instalado:

gpgconf
gpg:OpenPGP:C%3a\Program Files (x86)\gnupg\bin\gpg.exe
gpgsm:S/MIME:C%3a\Program Files (x86)\gnupg\bin\gpgsm.exe
keyboxd:Public Keys:C%3a\Program Files (x86)\gnupg\bin\keyboxd.exe
gpg-agent:Private Keys:C%3a\Program Files (x86)\gnupg\bin\gpg-agent.exe
scdaemon:Smartcards:C%3a\Program Files (x86)\gnupg\bin\scdaemon.exe
dirmngr:Network:C%3a\Program Files (x86)\gnupg\bin\dirmngr.exe
pinentry:Passphrase Entry:C%3a\Program Files (x86)\gnupg\bin\pinentry-basic.exe


git config --global gpg.program "C:\Program Files (x86)\gnupg\bin\gpg.exe"

Agradeço a leitura e até a próxima. 😎

Como habilitar para que as portas USB acordem o computador

Marks Duarte — Mon, 01 May 2023 18:06:02 +0000

Testado no Ubuntu 23.04

Liste os dispositivos que podem acordar o sistema:

grep . /sys/bus/usb/devices/*/power/wakeup

O resultado será uma lista de dispositivos com a indicação de habilitado ou desabilitado:

/sys/bus/usb/devices/usb1/power/wakeup:disabled
/sys/bus/usb/devices/usb2/power/wakeup:disabled
/sys/bus/usb/devices/usb3/power/wakeup:disabled
/sys/bus/usb/devices/usb4/power/wakeup:disabled

Agora vamos editar o arquivo rc.local para habilitar os dispositivos mesmo após o reinicio do sistema:

sudo nano /etc/rc.local

echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeup
echo enabled > /sys/bus/usb/devices/usb3/power/wakeup
echo enabled > /sys/bus/usb/devices/usb4/power/wakeup

Salve o arquivo e pronto.

Espero ter ajudado.

Configurando o Spring Boot Admin: Server e Client

Marks Duarte — Sat, 08 Apr 2023 02:28:06 +0000

Existem várias formas de se monitorar sistemas distribuídos e uma que me agrada bastante pela simplicidade de configuração e confiabilidade é o Spring Boot Admin.

Nesse tutorial criaremos duas aplicações utilizando o Spring Boot, uma que será o servidor de monitoramento e a outra, o cliente que deverá se registrar para ser monitorado.

Também vamos aproveitar para implementar uma camada de segurança utilizando o Spring Security e com o #Maven, poderemos fazer o build das aplicações para serem executadas individualmente.

Versões utilizadas

Spring Boot: 2.7.10
Spring Boot Admin Server: 2.7.10
Spring Boot Admin Client: 2.7.10

Configurando o Servidor

Crie um projeto utilizando o Spring Initilizr com as seguintes dependências:

Starter Web
Starter Security
Admin Starter Server

Confira se as dependências relacionadas ao Spring Boot Admin foram adicionadas:



...
<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-server</artifactId>
</dependency>
<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-server-ui</artifactId>
</dependency>
...

Adicione a anotação @EnableAdminServer em alguma classe de configuração:



...

@EnableAdminServer
@SpringBootApplication
public class SpringBootAdminServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringBootAdminServerApplication.class, args);
    }

}

Configure o comportamento da aplicação utilizando o arquivo application.yaml. Como adicionamos uma camada de segurança, devemos criar um nome de usuário e senha para logarmos no servidor e também será necessário configurar o login para comunicação entre servidor e cliente.



server:
  port: 8081
  servlet:
    context-path: /admin-console
spring:
  security:
    user:
      # Configura o login do servidor.
      name: ${SBA_SERVER_USERNAME}
      password: ${SBA_SERVER_PASSWORD}
  boot:
    admin:
      client:
        # Necessários para que o cliente possa se registrar na api do servidor protegido.
        username: ${SBA_SERVER_USERNAME}
        password: ${SBA_SERVER_PASSWORD}
        instance:
          metadata:
            user:
              # Necessários para que o servidor possa acessar os endpoints protegidos do cliente.
              name: ${SBA_CLIENT_USERNAME}
              password: ${SBA_CLIENT_PASSWORD}

# LOG
logging:
  file:
    name: ${user.home}/logs/admin/sba-server.log
  level:
    root: info
    web: info
    dev.marksduarte: info
    org.springframework: info
  charset:
    file: utf-8

Agora vamos configurar o Spring Security criando uma classe e desabilitando o proxy dos beans na anotação @Configuration(proxyBeanMethods = false), pois como vamos trabalhar com @bean autocontido, podemos evitar o processamento da subclasse CGLIB.

Também vamos permitir os acessos às rotas de login e assets e desabilitar a proteção CSRF paras o métodos HTTP POST e HTTP DELETE nas instâncias dos clientes.



package dev.marksduarte.springbootadminserver;

import de.codecentric.boot.admin.server.config.AdminServerProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.HttpMethod;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler;
import org.springframework.security.web.csrf.CookieCsrfTokenRepository;
import org.springframework.security.web.util.matcher.AntPathRequestMatcher;

@Configuration(proxyBeanMethods = false)
public class SecurityConfig {

    private final AdminServerProperties adminServer;

    public SecurityConfig(AdminServerProperties adminServer) {
        this.adminServer = adminServer;
    }

    @Bean
    protected SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        SavedRequestAwareAuthenticationSuccessHandler successHandler = new SavedRequestAwareAuthenticationSuccessHandler();
        successHandler.setTargetUrlParameter("redirectTo");
        successHandler.setDefaultTargetUrl(this.adminServer.path("/"));

        http.authorizeHttpRequests(authorizeRequests -> authorizeRequests
                        .requestMatchers(new AntPathRequestMatcher(this.adminServer.path("/assets/**")))
                        .permitAll()
                        .requestMatchers(new AntPathRequestMatcher(this.adminServer.path("/login")))
                        .permitAll()
                        .anyRequest()
                        .authenticated())
                .formLogin(formLogin -> formLogin.loginPage(this.adminServer.path("/login"))
                        .successHandler(successHandler))
                .logout(logout -> logout.logoutUrl(this.adminServer.path("/logout")))
                .httpBasic(Customizer.withDefaults())
                .csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
                        .ignoringRequestMatchers(
                                new AntPathRequestMatcher(this.adminServer.path("/instances"), HttpMethod.POST.toString()),
                                new AntPathRequestMatcher(this.adminServer.path("/instances/*"), HttpMethod.DELETE.toString()),
                                new AntPathRequestMatcher(this.adminServer.path("/actuator/**"))));

        return http.build();
    }
}

Pronto, agora é só rodar a aplicação e conferir se o Admin Server está acessível através do endereço http://localhost:8081/admin-console e logar com o usuário e senha informados na configuração.

Configurando o Cliente

Crie um projeto utilizando o Spring Initilizr com as seguintes dependências:

Starter Web
Starter Actuator
Starter Security
Admin Starter Client

Confira no seu arquivo pom.xml, se a dependência do Spring Boot Admin Client e Spring Actuator foram adicionadas:



...
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-client</artifactId>
    <version>2.7.10</version>
</dependency>
...

Agora vamos configurar o sistema começando pelo arquivo application.yaml:



## INFO ENDPOINT
## Aqui configuramos as informações sobre o sistema, como nome, descrição, versão e etc.
info:
  name: Spring Boot Admin Client
  description: Sistema Cliente
  version: @project.version@

server:
  port: 8080
  servlet:
    context-path: /admin-client

spring:
  # Configuração básica do Spring Security.
  security:
    user:
      name: ${SBA_CLIENT_USERNAME}
      password: ${SBA_CLIENT_PASSWORD}
  boot:
    admin:
      client:
        enabled: true
        # URL do servidor que o cliente deve se registrar.
        url: http://localhost:8081/admin-console
        username: ${SBA_SERVER_USERNAME}
        password: ${SBA_SERVER_PASSWORD}
        instance:
          # URL base para calcular o service-url com o qual se registrar. O caminho é inferido em tempo de execução e anexado à url base.
          service-base-url: http://localhost:8080
          # Essas informações são passadas ao servidor para que ele possa fazer o acesso aos endpoints do sistema cliente.
          metadata:
            user:
              name: ${SBA_SERVER_USERNAME}
              password: ${SBA_SERVER_PASSWORD}
        auto-deregistration: true

## APP
app:
  cors-origins:
    - http://localhost
  cors-methods:
    - GET
    - POST
    - PUT
    - DELETE
    - OPTIONS
  cors-headers:
    - Authorization
    - Content-Type
    - Content-Length
    - X-Requested-With

## ACTUATOR
management:
  info:
    env:
      # Desde o Spring Boot 2.6, o env info é desabilitado por padrão.
      enabled: true
  endpoint:
    health:
      show-details: ALWAYS
      enabled: true
    shutdown:
      enabled: true
    logfile:
      enabled: true
      external-file: logs/sba-client.log
  endpoints:
    web:
      exposure:
        # Liberamos todos os endpoints, mas lembre-se, em produção não se deve fazer isso.
        include: "*"
      cors:
        allowed-headers: ${app.cors-headers}
        allowed-methods: ${app.cors-methods}
        allowed-origins: ${app.cors-origins}

## LOG
logging:
  file:
    name: logs/sba-client.log
    path: logs
  level:
    root: info
    web: info
    dev.marksduarte: info
  charset:
    file: utf-8
  logback:
    rollingpolicy:
      clean-history-on-start: true
      max-file-size: 10MB

Para simplificar, vamos habilitar todas as requisições para os endpoints do "/actuator/**":



...

@EnableWebSecurity
@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf()
                .disable()
                .authorizeHttpRequests()
                .antMatchers("/actuator/**")
                .permitAll();
        return http.build();
    }
}

Bom, isso já é suficiente para registar nossa aplicação cliente no servidor.

Mas caso aconteça alguma exceção do tipo: HttpMessageNotWritableException ou um response error HTTP 416 ao tentar acessar o arquivo de log, não se assuste, isso pode acontecer caso seu sistema tenha alguma classe de configuração do Jackson que estenda WebMvcConfigurationSupport.

Nesse caso, essa classe pode estar desativando a instanciação dos Beans com as configurações padrões do Spring Boot.

Para corrigir esse tipo de problema, podemos criar um Bean customizado e substituir a configuração padrão criada na inicialização do sistema.



@Configuration
public class JacksonConfig extends WebMvcConfigurationSupport {

    private final Jackson2ObjectMapperBuilder builder = Jackson2ObjectMapperBuilder.json();

    private static final List<MediaType> MEDIA_TYPE_LIST = List.of(
            MediaType.ALL,
            MediaType.parseMediaType("application/vnd.spring-boot.actuator.v2+json")
    );

    @Bean
    public MappingJackson2HttpMessageConverter customMappingJackson2HttpMessageConverter() {
        MappingJackson2HttpMessageConverter converter = actuatorConverter();
        converter.setSupportedMediaTypes(MEDIA_TYPE_LIST);
        return converter;
    }

    private MappingJackson2HttpMessageConverter actuatorConverter() {
        return new MappingJackson2HttpMessageConverter(builder.build()) {
            @Override
            protected boolean canWrite(MediaType mediaType) {
                // O método super, retorna true se for null.
                // Assim evitamos a exceção _HttpMessageNotWritableException_ caso o Content-Type 'null' seja enviado.
                return mediaType != null && super.canWrite(mediaType);
            }
        };
    }

    @Override
    protected void extendMessageConverters(List<HttpMessageConverter<?>> converters) {
        /*
        Remove somente o MappingJackson2HttpMessageConverter
padrão e substitui pelo customMappingJackson2HttpMessageConverter.
         */
        var defaultHttpConverterOpt = converters.stream()
                .filter(MappingJackson2HttpMessageConverter.class::isInstance)
                .findFirst();

        defaultHttpConverterOpt.ifPresent(converters::remove);
        converters.add(customMappingJackson2HttpMessageConverter());
    }
}

Código disponível em GitHub Marks Duarte

Por enquanto é só. Até mais! ;)

Como limitar o consumo de memória e processamento do WSL2

Marks Duarte — Mon, 20 Mar 2023 14:16:35 +0000

Ao utilizarmos o WSL2 no Windows, por padrão, o consumo de memória e de processamento fica sem restrição e esse comportamento pode acabar afetando o desempenho do Host.

Para contornarmos tal situação, podemos criar um arquivo de configuração chamado '.wslconfig' na pasta de usuário localizada em: c:\users\<username>\.wslconfig.

Agora informe as restrições desejadas conforme exemplo:

[wsl2]
memory=4GB # limita a memória da VM.
processors=2 # limita o uso da VM para 2 processadores virtuais

Após salvar as alterações, reinicie o serviço executando o seguinte comando como Administrador:

Restart-Service LxssManager

Para mais informações, consulte a documentação em: Microsoft

Como mover os discos virtuais do WSL2

Marks Duarte — Thu, 16 Mar 2023 20:42:52 +0000

Para quem gosta de manter seus arquivos em partições ou mesmo em discos separados, o Windows não ajuda muito na hora da instalação das distribuições Linux utilizando o WSL, e para fazermos essa migração só precisamos seguir alguns passos bem simples.

Mas antes, vamos listar as distribuições instaladas para escolhermos quais serão movidas:

wsl -l
Distribuições do Subsistema do Windows para Linux:
docker-desktop (Padrão)
Ubuntu-22.04
docker-desktop-data

Agora vamos fazer o processo de exportação da distribuição para um arquivo .tar.

Depois será necessário remover o registro dessa distribuição do WSL e por fim, reimportar informando o novo local de destino.

wsl --export Ubuntu-22.04 Ubuntu-22.04.tar
wsl --unregister Ubuntu-22.04
wsl --import Ubuntu-22.04 .\path\destino .\Ubuntu-22.04.tar

Atenção: a nova instância será redefinida para o usuário root. Caso tenha criado algum usuário antes, e queira continuar usando o mesmo, faça o seguinte:

cd HKCU:\

set-location -path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\

Get-childitem -recurse -ErrorAction SilentlyContinue | Get-ItemProperty | Where-Object {$_.DistributionName -like "Ubuntu-22.04"} | Set-Itemproperty -Name DefaultUid -Value 1000

E assim finalizamos essa primeira, de muitas, dicas.

Espero ter ajudado e até a próxima.

Ops! Já ia me esquecendo... Você também pode usar o script do #PowerShell que fiz para agilizar esse processo. ;)