Perguntas[wordpress](server)

Eu estava tentando criar um recurso wordpress - selecionei apenas a opção de serviços do Azure e ele mostrou uma opção de "wordpress escalável ....". tentei criar esse recurso. e isso me dá o erro abaixo.

Estou recebendo o erro abaixo

YAML

Copiar A solicitação de modelo excede as limitações de cota para um ou mais recursos Microsoft.Network na assinatura. Verifique os detalhes para obter informações sobre cada recurso e entre em contato com o suporte para aumentar a respectiva cota. (Código: TemplateExceedsResourceQuotaLimits) YAML

A assinatura de cópia 5d222a05-2a46-457d-b6cd-00f02680b7d2 tem uma cota de 10 para recursos do tipo PublicIpAddress com sku Standard. A assinatura possui atualmente 8 recursos e o modelo contém 3 novos recursos deste tipo que excedem a cota. Entre em contato com o suporte para aumentar a cota para o tipo de recurso PublicIpAddress (Código: ResourceCountExceedsLimitDueToTemplate)

A assinatura 5d222a05-2a46-457d-b6cd-00f02680b7d2 possui uma cota de 10 para recursos do tipo PublicIpAddress com sku Standard. A assinatura possui atualmente 8 recursos e o modelo contém 3 novos recursos deste tipo que excedem a cota. Entre em contato com o suporte para aumentar a cota para o tipo de recurso PublicIpAddress (Código: ResourceCountExceedsLimitDueToTemplate)

Pretendo mover cerca de 500 sites WordPress de suas respectivas VMs individuais para um único servidor para eficiência e economia de custos.

Nesse único servidor terei instalações separadas para cada site. Eles terão seus próprios diretórios e compartilharão apenas um pluginslink simbólico comum para manter os plug-ins atualizados em todos os aspectos.

É seguro o suficiente tê-los lado a lado em seus respectivos diretórios?

Preciso chegar ao ponto de criar um usuário do sistema para cada instalação que tenha apenas acesso de gravação a esses arquivos?

É seguro ter os bancos de dados próximos um do outro, mesmo que eles tenham nomes de usuário individuais que SOMENTE tenham acesso a esse banco de dados (não há root com acesso "onisciente" - $ show databases;).

Devo prender cada instalação?

Devo colocar cada instalação em um contêiner?

Eu considerei a instalação do WP Multisite, mas meu eu paranóico pode ver tantos problemas com isso.

Eu tentei pesquisar isso e pesquisar e pesquisar, mas continuo encontrando razões para NÃO instalar vários sites WP em um único servidor.

Devo colocá-los atrás de um IP Cloudfare?

Estou dando muita importância a isso? Tenho um histórico fantástico de nenhum compromisso de WP e gostaria de mantê-lo assim.

Este é um servidor VM dedicado auto-hospedado. O ambiente é

• VCloud VMWare
• Ubuntu 20.04.2LTS
• PHP 8.1
• Apache 2.4
• MySQL versão 8.0.23
• WordPress mais recente

Instalei um site wordpress na digitalocean e fiz todas as anotações de DNS e está preenchido conforme https://www.whatsmydns.net/ . Porém, a única página que possui o nome de domínio e a página inicial, as demais páginas e posts possuem o endereço IP. Alguém pode me dizer o que poderia ser, por favor?

para começar, tenho muito pouco conhecimento sobre a configuração, mas tenho uma pergunta a fazer.

Eu tenho dois sites com o domínio

1. site1.domínio.com
2. sites.domínio.com

Em cada domínio, compro outro domínio para eles.

1. site1.com
2. site2.com

Gostaria de perguntar, como posso configurar o website1.com e website2.com para encaminhar para website1.domain.com e website2.domain.com?

Quando um usuário vai para website1.com, ele NÃO será REDIRECIONADO para website1.domain.com, mas ainda será o mesmo URL (website1.com)? E como posso usar o Let's Encrypt para configurar o SSL para cada site?

Observação:

1. Estou usando o Nginx para configurar o domínio para website1.domain.com e website2.domain.com

É o mesmo que o WordPress permite que o usuário configure seu próprio domínio em seu site pessoal do WordPress. Eu não sou um especialista em DevOps, então vocês podem me dar uma solução ou alguma palavra-chave para pesquisar?

Eu tenho um site wordpress no qual fiz um teste de carga pesada. Como você pode ver abaixo, o uso da CPU é alto, mas ao mesmo tempo o uso da RAM nunca ultrapassa 0,4%. O teste de carregamento não produz erros, mas o tempo de carregamento do site é muito longo. Estou preocupado que a capacidade disponível da RAM não seja realmente usada. Ou esse baixo uso de RAM é normal para 10.000 clientes/segundo?

Especificações do servidor:

• CPU: Processador AMD Ryzen 7 PRO 3700 de 8 núcleos (16 núcleos)
• RAM: 64GB
• SSD: 960 GB NVMe
• Largura de banda: 1 Gbps
• SO: Ubuntu 20.04.4 LTS

Nenhum cache ativado

Eu recebo esses resultados com o topcomando

top - 14:12:22 up  4:11,  2 users,  load average: 29.49, 16.27, 7.29
Tasks: 467 total, 143 running, 301 sleeping,  23 stopped,   0 zombie
%Cpu(s): 27.6 us, 45.5 sy,  0.0 ni, 24.8 id,  0.0 wa,  0.0 hi,  2.1 si,  0.0 st
MiB Mem :  64306.9 total,  50683.7 free,   7559.5 used,   6063.7 buff/cache
MiB Swap:   7630.0 total,   7630.0 free,      0.0 used.  55881.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  37346 nginx     20   0  270356 266728   6364 R  78.1   0.4   2:19.89 nginx
  57982 fibonac+  20   0  355720 153908 105132 S  14.0   0.2   0:03.36 php-fpm
  61772 fibonac+  20   0  353552 150692 105776 S  14.0   0.2   0:01.26 php-fpm
   1524 mysql     20   0 9117616 192712  20468 S  13.6   0.3   1:17.50 mysqld
  57048 fibonac+  20   0  355788 153888 105072 S  13.6   0.2   0:04.08 php-fpm
  59186 fibonac+  20   0  353712 151920 105132 S  13.6   0.2   0:02.86 php-fpm
  61435 fibonac+  20   0  353680 150108 105120 R  13.6   0.2   0:01.66 php-fpm
  57693 fibonac+  20   0  355760 153964 105132 S  13.3   0.2   0:04.53 php-fpm
  59195 fibonac+  20   0  353684 151912 105124 S  13.3   0.2   0:02.86 php-fpm
  51154 fibonac+  20   0  357824 156160 105136 R  12.3   0.2   0:08.10 php-fpm
  51197 fibonac+  20   0  357780 156064 105088 R  12.0   0.2   0:07.05 php-fpm
  58034 fibonac+  20   0  355728 153616 105132 R  11.0   0.2   0:03.17 php-fpm
  51261 fibonac+  20   0  357780 156064 105136 R  10.0   0.2   0:06.74 php-fpm
  52563 fibonac+  20   0  358116 162056 110892 R  10.0   0.2   0:06.62 php-fpm
  57410 fibonac+  20   0  355728 153948 105132 R  10.0   0.2   0:03.86 php-fpm
  59521 fibonac+  20   0  351636 149816 105136 R  10.0   0.2   0:01.98 php-fpm
  60246 fibonac+  20   0  353752 151856 105140 R  10.0   0.2   0:02.70 php-fpm
  51147 fibonac+  20   0  357812 156156 105136 R   9.6   0.2   0:07.93 php-fpm
  51210 fibonac+  20   0  357780 156136 105136 R   9.6   0.2   0:08.08 php-fpm
  51225 fibonac+  20   0  357776 156112 105128 R   9.6   0.2   0:07.47 php-fpm
  51241 fibonac+  20   0  357780 156112 105136 R   9.6   0.2   0:06.95 php-fpm
  51251 fibonac+  20   0  357784 156072 105136 R   9.3   0.2   0:06.92 php-fpm
  51255 fibonac+  20   0  357784 156132 105140 R   9.3   0.2   0:07.43 php-fpm
  57054 fibonac+  20   0  355784 153952 105124 R   9.3   0.2   0:03.91 php-fpm
  57056 fibonac+  20   0  355768 153960 105132 R   9.3   0.2   0:03.85 php-fpm
  59192 fibonac+  20   0  353708 151508 105120 R   9.3   0.2   0:02.73 php-fpm
  61746 fibonac+  20   0  343316 140124 105140 R   9.3   0.2   0:00.74 php-fpm
  51233 fibonac+  20   0  357776 156112 105140 R   9.0   0.2   0:06.65 php-fpm
  51243 fibonac+  20   0  357784 156140 105120 R   9.0   0.2   0:07.97 php-fpm
  55161 fibonac+  20   0  355728 153988 105132 R   9.0   0.2   0:04.28 php-fpm
  57424 fibonac+  20   0  355736 153600 105132 R   9.0   0.2   0:03.30 php-fpm
  59185 fibonac+  20   0  353684 151496 104832 R   9.0   0.2   0:02.73 php-fpm
  51177 fibonac+  20   0  357812 156132 105136 R   8.6   0.2   0:07.17 php-fpm
  57401 fibonac+  20   0  355728 153620 105132 R   8.6   0.2   0:03.25 php-fpm
  51239 fibonac+  20   0  357836 156128 105136 R   8.3   0.2   0:06.93 php-fpm
  54835 fibonac+  20   0  357776 155544 104892 R   8.3   0.2   0:04.93 php-fpm
  61764 fibonac+  20   0  345492 143512 105588 R   8.3   0.2   0:01.07 php-fpm
  50951 fibonac+  20   0  357860 156164 105140 R   8.0   0.2   0:08.77 php-fpm
  51024 fibonac+  20   0  357816 156128 105136 R   8.0   0.2   0:07.97 php-fpm
  51160 fibonac+  20   0  357808 156156 105136 R   8.0   0.2   0:07.45 php-fpm
  54833 fibonac+  20   0  357832 155788 104816 R   8.0   0.2   0:06.09 php-fpm
  57047 fibonac+  20   0  355788 153864 105068 R   8.0   0.2   0:03.91 php-fpm
  59193 fibonac+  20   0  355760 153208 105080 R   8.0   0.2   0:03.08 php-fpm
  63679 fibonac+  20   0  260456 107648  80836 R   8.0   0.2   0:00.24 php-fpm
  63682 fibonac+  20   0  260456 107672  80860 R   8.0   0.2   0:00.24 php-fpm
  51028 fibonac+  20   0  357856 156068 105136 R   7.6   0.2   0:06.58 php-fpm
  53620 fibonac+  20   0  357776 156048 105132 R   7.6   0.2   0:05.68 php-fpm
  54832 fibonac+  20   0  357776 155968 105052 R   7.6   0.2   0:05.61 php-fpm
  55152 fibonac+  20   0  357780 156040 105132 R   7.6   0.2   0:05.36 php-fpm
  57981 fibonac+  20   0  355732 153596 105132 R   7.6   0.2   0:03.30 php-fpm
  58035 fibonac+  20   0  355736 153604 105132 R   7.6   0.2   0:03.29 php-fpm
  59184 fibonac+  20   0  353736 151484 105100 R   7.6   0.2   0:02.47 php-fpm
  59189 fibonac+  20   0  356072 159176 110760 R   7.6   0.2   0:05.38 php-fpm
  63683 fibonac+  20   0  260456 106668  80072 R   7.6   0.2   0:00.23 php-fpm
  51208 fibonac+  20   0  357780 156188 105140 R   7.3   0.2   0:07.25 php-fpm
  51237 fibonac+  20   0  357776 156184 105136 R   7.3   0.2   0:07.43 php-fpm

Depois de configurar o Apache 2.4 e o Wordpress, recebo a seguinte mensagem de erro SSL:

$ wget "https://example.com"
Resolving example.com (example.com)... 192.168.15.5
Connecting to example.com (example.com)|192.168.15.5|:443... connected.
ERROR: no certificate subject alternative name matches
requested host name ‘ example.com’.
To connect to example.com insecurely, use `--no-check-certificate'.

Para fazer com que o nome de domínio corresponda ao meu certificado SSL ( www.example.com), tentei ajustar a configuração do site para redirecionar https://example.com para https://www.example.com . No entanto, não está funcionando: O redirecionamento http-para-https funciona conforme o esperado, mas o domínio nu para o domínio www não.

Aqui está a configuração do meu site:

<VirtualHost *:80>
        ServerName example.com
        ServerAlias www.example.com
        Redirect permanent / https://www.example.com/
</VirtualHost>
                                                                                                  
<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
            ServerName www.example.com

            Protocols h2 http/1.1

            ServerAdmin webmaster@localhost
            DocumentRoot /var/www/html
            DirectoryIndex index.php

            RewriteEngine on            #### Doesn’t work at all ####
            RewriteCond %{HTTP_HOST} ^example\.com [NC]
            RewriteRule ^/(.*) https://www.example.com/$1 [L,R=301]


            ErrorLog ${APACHE_LOG_DIR}/error.log
            CustomLog ${APACHE_LOG_DIR}/access.log combined

            # SSL with Letsencrypt                                                                                                                Include /etc/letsencrypt/options-ssl-apache.conf
            SSLEngine on
            SSLCertificateFile      /etc/letsencrypt/live/www.example.com/fullchain.pem
            SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
                                                                             
    </VirtualHost>
</IfModule>

O site em si funciona bem e .htaccesscontém apenas as linhas criadas pelo Wordpress.

Qualquer entrada é apreciada.

Feito um novo tema no Wordpress, o novo tema é muito parecido com o antigo, ou seja, não deve haver nenhuma grande alteração nas consultas SQL, provavelmente menos, mas o site é lento e parece que vem de verniz.

Como faço para depurar o verniz para ver quais consultas não estão recebendo um acerto de cache? Estou suspeitando que seja alguma chamada ajax, mas existem 100 delas, então preciso saber qual ajax não está sendo armazenado em cache. Como você faz isso?

Hoje eu atualizei meu servidor web do Debian Buster para Bullseye e foi de fato uma atualização bastante simples. Tudo parecia funcionar até que tentei acessar alguns sites WordPress no servidor. No começo, recebi algum erro sobre um módulo MySQL ausente. A mensagem de erro que recebi do PHPMyAdmin me deu uma pista melhor: dizia que estava faltando o módulo mysqli.

Então eu instalei apt install php7.4-mysqli e isso de fato fez meus sites WordPress funcionarem novamente.

O único problema agora é que não consigo atualizar o Wordpress. Toda vez que tento atualizar o WordPress, recebo um erro:

Eu suspeito que preciso instalar o suphp. Mas antes de eu fazer, alguém pode confirmar que este é realmente o caso? Ou preciso fazer outra coisa após a atualização do Buster para o Bullseye?

EDIT: Demorei um pouco para descobrir o que realmente estava acontecendo. Agora eu sei, não tenho idéia de como resolver o problema.

A mensagem de erro que o WP está dando, na verdade está incorreta. Como se vê, é capaz de descompactar a atualização muito bem na pasta apropriada. Mas é quando ele verifica se os arquivos foram realmente descompactados, que dá errado. O problema está neste pedaço de código em update-core.php :

foreach ( $roots as $root ) {
  if ( $wp_filesystem->exists( $from . $root . 'readme.html' )
    && $wp_filesystem->exists( $from . $root . 'wp-includes/version.php' )
  ) {
    $distro = $root;
    break;
  }
}
    
if ( ! $distro ) {
  $wp_filesystem->delete( $from, true );
  return new WP_Error( 'insane_distro', __( 'The update could not be unpacked.' ) );
}

O que ele faz aqui é simplesmente verificar se existem dois arquivos na pasta para a qual acabou de descompactar o arquivo zip. Isso falha. E o motivo é o seguinte:

Eu uso o método FTP para instalar atualizações. Então, quando eu digo para atualizar, ele primeiro descobre a pasta para a qual deve baixar o arquivo zip. Esta pasta é armazenada em $working_dir e é usada a partir desse momento para o resto do processo de atualização. O verdadeiro caminho no servidor é, /domains/domainname.com/htdocs/wp-content/upgrade/mas como os usuários de FTP estão em chroot, o WP encontra e armazena /htdocs/wp-content/upgrade/. O arquivo de atualização é baixado para esta pasta e, em seguida, descompactado.

Em seguida, ele faz a verificação acima. E isso falha porque tenta encontrar um arquivo /htdocs/wp-content/upgrade/enquanto o local verdadeiro é /domains/domainname.com/htdocs/wp-content/upgrade/.

Eu entendo por que ele baixa o pacote muito bem (já que os usuários de FTP estão em chroot). Mas não entendo por que não falha ao descompactar depois, mas falha ao verificar a existência dos arquivos ...

Eu verifiquei todas as configurações do php e não consigo encontrar nada diferente com as configurações de antes da atualização do Debian…

Acho que a nova versão (V5.9) do Wordpress adiciona esta linha ao .htaccess:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

A versão antiga do Wordpress não tem essa linha. O que isto significa? Posso removê-lo?

Estou recebendo o mesmo erro nos meus dois sites WordPress:

Sua pasta de conteúdo em "/home/{my_user}/public_html/wp-content/uploads" não é gravável.

Ambos estão hospedando em um serviço dedicado usando WHM.

Alterei a permissão na pasta ../uploads/ para 777 e funciona, mas não acho que seja um exercício válido. A configuração atual na pasta é 775

Você pode me dar alguns passos para diagnosticar este?