wruckie's questions

Estou usando Ubuntu 22.04 LTS e Postfix para enviar mensagens através do SendGrid. Segui o tutorial aqui https://www.twilio.com/docs/sendgrid/for-developers/sending-email/postfix

Tenho vários VPS's e uso apelidos para mantê-los separados na minha cabeça - esse chamei de COCONUT. Algumas mensagens serão enviadas se o fromendereço estiver escrito, mas todas as mensagens do sistema não serão enviadas. Ao enviar um , ele tenta enviar de Recebo o erro porque o SendGrid sabe que não tenho permissões apenas de "coco", daí o erro de identidade do remetente.ps -ely | mailx -s Testing [email protected]from=<root@coconut>

entradas de log /var/log/mail.logao executar umps -ely | mailx -s Testing [email protected]

...
Jul 19 09:28:57 coconut postfix/pickup[624347]: 290E754988: uid=0 from=<root@coconut>
Jul 19 09:28:57 coconut postfix/cleanup[624480]: 290E754988: message-id=<[email protected]>
Jul 19 09:28:57 coconut postfix/qmgr[624348]: 290E754988: from=<root@coconut>, size=17599, nrcpt=1 (queue active)
Jul 19 09:28:57 coconut postfix/smtp[624482]: 290E754988: to=<[email protected]>, relay=smtp.sendgrid.net[44.239.172.8]:587, delay=0.83, delays=0.01/0.01/0.6/0.2, dsn=5.0.0, status=bounced (host smtp.sendgrid.net[44.239.172.8] said: 550 The from address does not match a verified Sender Identity. Mail cannot be sent until this error is resolved. Visit https://sendgrid.com/docs/for-developers/sending-email/sender-identity/ to see the Sender Identity requirements (in reply to end of DATA command))
Jul 19 09:28:57 coconut postfix/cleanup[624480]: F2DC254989: message-id=<[email protected]>
Jul 19 09:28:57 coconut postfix/bounce[624483]: 290E754988: sender non-delivery notification: F2DC254989
Jul 19 09:28:57 coconut postfix/qmgr[624348]: F2DC254989: from=<>, size=20071, nrcpt=1 (queue active)
Jul 19 09:28:57 coconut postfix/qmgr[624348]: 290E754988: removed
...

Aqui está o meu/etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
myhostname = coconut.example.com
myorigin = example.com
mydestination = $myhostname, localhost #added to no effect

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2

#header_checks = regexp:/etc/postfix/my_custom_header
inet_protocols = ipv4
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
header_size_limit = 4096000
relayhost = [smtp.sendgrid.net]:587

Aqui está o conteúdo do meu/etc/mailname

example.com

Aqui está o conteúdo do meu/etc/hostname

coconut.example.com

Alguma idéia de como corrigir os e-mails do sistema enviados de root@coconut?

Após uma atualização para o Ubuntu 20.04 LTS, meu site WordPress está travado no modo de manutenção. O mySQL está tentando iniciar com essas mesmas 10 linhas se repetindo a cada dois segundos no /var/log/mysql/error.logarquivo. Pelo menos para mim, uma busca rápida pelo termo unknown variable 'query_cache_limit=1M'só gera páginas informando como implementar esse parâmetro. Como faço para voltar a funcionar?

2020-11-12T16:12:25.733349Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-11-12T16:12:25.735469Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.22-0ubuntu0.20.04.2) starting as process 20068
2020-11-12T16:12:25.746199Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-11-12T16:12:26.131087Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2020-11-12T16:12:26.307241Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2020-11-12T16:12:26.370126Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-11-12T16:12:26.370481Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2020-11-12T16:12:26.377752Z 0 [ERROR] [MY-000067] [Server] unknown variable 'query_cache_limit=1M'.
2020-11-12T16:12:26.378449Z 0 [ERROR] [MY-010119] [Server] Aborting
2020-11-12T16:12:27.821939Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.22-0ubuntu0.20.04.2)  (Ubuntu).

Após uma atualização para o Ubuntu 20.04, alguns pacotes têm "{u}" em seu nome. Procurei a resposta, mas parece que o Google está ignorando prontamente as chaves durante a pesquisa ou isso não acontece muito. Alguém pode me ajudar com links para documentação? O que o {u} significa nesses nomes de pacotes?

user@server:~# sudo aptitude update && sudo aptitude upgrade && sudo apt-get autoremove
Hit http://mirrors.linode.com/ubuntu focal InRelease
Hit http://mirrors.linode.com/ubuntu focal-updates InRelease
Hit http://mirrors.linode.com/ubuntu focal-backports InRelease
Hit http://security.ubuntu.com/ubuntu focal-security InRelease
Hit http://ppa.launchpad.net/ondrej/php/ubuntu focal InRelease

The following packages will be REMOVED:
  ack{u} libargon2-0{u} libfile-next-perl{u} libicu65{u}
  python-pkg-resources{u}
0 packages upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 34.4 MB will be freed.
Do you want to continue? [Y/n/?]

Hoje à noite eu atualizei meu VPS do Ubuntu 16.04 LTS para o Ubuntu 18.04 LTS. Tudo funcionou como esperado, teve uma pequena limpeza no corredor php 5.6 e algumas prateleiras de estoque no corredor php 7.4. O Apache reiniciou sem um gemido depois de todas as minhas alterações de configuração e mod; pensei que eu era bom para ir. Mas 3 dos meus 4 sites não carregavam; nenhuma página 404 limpa, apenas esta mensagem de configuração incorreta.

Internal Server Error 
The server encountered an internal error or misconfiguration and was unable to complete your request.

Depois de analisar o /var/log/apache2/error.log, encontrei isso:

[Wed May 06 03:55:16.190469 2020] [core:alert] [pid 5657] [client 10.10.10.10:56897] 
/var/www/abc/example.com/.htaccess: No comments are allowed here, referer: https://example.com/

Depois de tentar várias coisas diferentes, parece que os comentários que iniciam a linha NÃO são o problema, são os comentários que terminam uma linha normal do arquivo. Remover ou mover esses #main officecomentários para suas próprias linhas traz tudo de volta online. A # Allow from this IP addresslinha ainda está no meu arquivo .htaccess, mas não me causa nenhum problema.

<Files wp-login.php>
    order deny,allow
    Deny from all
#   
#   Allow from this IP address
    allow from 10.10.10.10      #main office
    allow from 10.10.11.10      #satellite office
</Files>

Isso é um erro ou uma característica'? Uma busca no Google por ".htaccess: Nenhum comentário é permitido aqui" não traz quase nada. (Você sabe que está com problemas quando o 4º hit é em uma língua estrangeira). Obviamente, o salto para o Ubuntu 18.04 ou as atualizações associadas do apache ou php são o 'quando', mas por quê? Por que essa documentação em linha é problemática? O que da?

Comprei um aplicativo da web que não usa caracteres especiais. Ao revisar meus logs, estou vendo a sondagem de agentes de ameaças que tentam ver se meu site é vulnerável à injeção de SQL adicionando apóstrofos e outros caracteres char() que normalmente nunca são usados. Eu confio na segurança do meu aplicativo (principalmente), mas queria ver se uma regra de reescrita ou alguma outra metodologia iria bloquear sua solicitação. Meu aplicativo da web fornece seu erro padrão. Estou procurando regras ou idéias para 1.) fornecer ao invasor o mínimo de informações possível sem 2.) adicionar muita sobrecarga ao servidor. Existem muitos exemplos de regras de reescrita por aí, mas nenhum que eu encontrei que lida com esse ângulo.

Exemplo simples da sondagem:https://sub.domain.com/default.aspx?page=3500'A=0&Id=497066

Estou usando o certbot para gerar um certificado SSL para um aplicativo da web de terceiros. Como não consigo acessar o código-fonte ou a estrutura de pastas, estou usando a validação de DNS. Para complicar ainda mais as coisas, meu provedor de DNS não deixa claro quando as alterações foram aplicadas e estão se propagando. Eu tenho que iniciar o processo, obter os valores, publicá-los no DNS, esperar um pouco e pressionar ENTER para concluir a validação. Se o tempo que esperei não foi longo o suficiente, ou a sessão do terminal para o servidor morre, tenho que começar de novo - o que gera novos valores para serem colocados no DNS.

Gostaria de consultar meus servidores de nomes DNS para ver se e quando meu _acme_challengevalor foi propagado. Let's Encrypt tem um meio de verificar esse valor, mas não consigo descobrir isso. Todos os fóruns online que estou encontrando são para consultar o registro TXT padrão usado para SPF.

Saída do processo de validação do certbot

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.app.mydomain.com with the following value:

4Rn5ZNCdLYDYK9uQnyZ7k3CJ8kNsNyIJa9QeXCeOCMI

Before continuing, verify the record is deployed.
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet. Note that you might be
asked to create multiple distinct TXT records with the same name. This is
permitted by DNS standards.)

Como faço para consultar esse registro TXT nomeado ?