tilkov's questions

Estou me conectando ao MySQL com o usuário 'feedbackdev', mas as consultas são executadas com 'feedback', que é outro usuário no mesmo servidor.

root@board:~# mysql -u feedbackdev -p feedbackdev
Enter password: 

mysql> select user();
+-----------------------+
| user()                |
+-----------------------+
| feedbackdev@localhost | 
+-----------------------+


mysql> select rating, COUNT(*) AS rating_count from order_feedback_view where feedback_created_at >= '2024-10-26 09:01:29' group by rating;
ERROR 1143 (42000): SELECT command denied to user 'feedback'@'localhost' for column 'source_id' in table 'orders'

Aqui estão as SUBVENÇÕES para os usuários

mysql> show grants for 'feedbackdev'@'localhost';
+----------------------------------------------------------------------+
| Grants for feedbackdev@localhost                                     |
+----------------------------------------------------------------------+
| GRANT PROCESS, SUPER ON *.* TO `feedbackdev`@`localhost`             |
| GRANT SET_USER_ID ON *.* TO `feedbackdev`@`localhost`                |
| GRANT ALL PRIVILEGES ON `feedbackdev`.* TO `feedbackdev`@`localhost` |
+----------------------------------------------------------------------+
3 rows in set (0.00 sec)

mysql> show grants for 'feedback'@'localhost';
+---------------------------------------------------------------------------+
| Grants for feedback@localhost                                             |
+---------------------------------------------------------------------------+
| GRANT PROCESS, SUPER, REPLICATION CLIENT ON *.* TO `feedback`@`localhost` |
| GRANT FLUSH_TABLES ON *.* TO `feedback`@`localhost`                       |
| GRANT ALL PRIVILEGES ON `feedback`.* TO `feedback`@`localhost`            |
+---------------------------------------------------------------------------+
3 rows in set (0.00 sec)

MySQL versão 8.0.40

Temos o Microsoft SQL Server 2008 R2 rodando no Windows Server 2008 R2, virtualizado no VMWare ESXi 6.7.0.

O servidor possui 2 soquetes de CPU com 22 núcleos cada. A VM é alocada em 8 soquetes com 3 núcleos cada e 64 GB de RAM (ServerEnterprise).

Dentro da VM vejo dois nós NUMA, cada um com 11 CPUs.

Infelizmente, o SQL Server usa apenas a CPU no NUMA Node 0 e o NUMA Node 1 está inativo.

O que estou fazendo errado? Estou limitado por licenciamento ou configuração incorreta?

Estou fazendo uma migração de mbox para mdbox em um novo disco. De /mnt/mail/$user para /mnt/mail2/$user

Local_correio atual = mbox:~/mail:INBOX=/mnt/mail/%u/mail/Inbox

O novo mail_location = mdbox:/mnt/mail2/$user/mdbox

Meu userdb principal é passwd, e eu tenho uma substituição para todos os usuários com outro userdb:

userdb {
  driver = passwd
  result_success = continue-ok
}

userdb {
  driver = passwd-file
  args = username_format=%u /etc/dovecot/passwd.override
  skip = notfound
}

Primeira etapa, substituindo mail_location para esse usuário:

$user:::::::userdb_mail_location=/mnt/mail2/%u/mdbox

Iniciando a migração:

doveadm sync -f -u $user mbox:/mnt/mail/$user/mail:INBOX=/mnt/mail/$user/mail/Inbox

A sincronização vai bem, todas as pastas e e-mails estão no local do mdbox em /mnt/mail2/$user/mdbox.

O diretório inicial desse usuário é então alterado de /mnt/mail/$user para /mnt/mail2/$user, as permissões são definidas.

/etc/passwd mostra que o diretório inicial do usuário é /mnt/mail2/$user.

/etc/dovecot/passwd.override tem o novo mdbox mail_location para esse usuário.

Infelizmente, quando um novo e-mail chega, ele ainda vai para a mbox antiga.

Postfix usa dovecot-lda como agente de entrega:

mailbox_command = /usr/lib/dovecot/dovecot-lda -f "$SENDER" -a "$RECIPIENT"

É possível que a dovecot-lda não entenda a substituição? E por que ele ainda entrega para o antigo $HOME para esse usuário, não importa que tenha sido alterado?

Tenho um serviço web para ser usado com ou sem certificado de cliente SSL. Os usuários terão acesso total somente quando seu navegador for autenticado com o certificado. Caso contrário, eles obtêm uma funcionalidade básica.

As configurações do nginx para isso são:

ssl_client_certificate /etc/nginx/client-cert/ca.crt;
ssl_verify_client optional;

O problema é que nenhum navegador solicita que o certificado seja selecionado ao se conectar ao serviço.

Qual é o comportamento que devo esperar quando ssl_verify_client é opcional? Devo ainda obter o prompt?

Se for, onde pode estar o problema?

Se não solicitar é o comportamento esperado, como forçaria o navegador a enviar esse certificado específico para o serviço?

Executando o nginx 1.10.3 no Ubuntu 16.04.4 LTS

configuração do nginx: https://pastebin.com/GwjVc0cZ