Erro com blocos de código: 403 Forbidden

Recentemente, assumi a gerência de um servidor de discourse e há alguns problemas.

  1. Tenho problemas persistentes ao tentar criar ou editar uma postagem com blocos de código. Ao tentar criar ou editar uma postagem com o bloco de código
(access node)$ spack list openfoam@2306
...
Variants:
    Name [Default]            When    Allowed values    Description
    ======================    ====    ==============    ==================================================

    build_system [generic]    --      generic           Build systems supported by the package
    int64 [off]               --      on, off           With 64-bit labels
    kahip [off]               --      on, off           With kahip decomposition
    knl [off]                 --      on, off           Use KNL compiler settings
    metis [off]               --      on, off           With metis decomposition
    mgridgen [off]            --      on, off           With mgridgen support
    paraview [off]            --      on, off           Build paraview plugins and runtime post-processing
    precision [dp]            --      sp, dp, spdp      Precision option
    scotch [on]               --      on, off           With scotch/ptscotch decomposition
    source [on]               --      on, off           Install library/application sources and tutorials
    vtk [off]                 --      on, off           With VTK runTimePostProcessing
    zoltan [off]              --      on, off           With zoltan renumbering
...

Recebo um erro 403 Forbidden.

  1. O Markdown não suporta realce de sintaxe; adicionar qualquer especificação de sintaxe resulta em um erro 403 Forbidden.

  2. Segmentos de código em linha também causam 403 Forbidden em alguns, mas não em todos os locais, em relação a outros blocos de código.

A versão instalada é 3.1.1 ( 0612f0d5b6 ).

Esses problemas estão relacionados e o que poderia estar causando esse comportamento?

Postagem de exemplo: Compiling OpenFOAM with Spack - 📚 Knowledge nuggets - HPC discourse

Resultado pretendido:

Existem alguns problemas ao instalar o OpenFOAM da OpenCFD com Spack.

Um ambiente foi configurado para gerenciar os pacotes com Spack seguindo as instruções do tutorial UL HPC. Em resumo, as seguintes dependências foram definidas para os pacotes SPACK,

(access node)$ cat << EOF > $SPACK_ROOT/etc/spack/packages.yaml
packages:
    slurm:
        externals:
        - spec: slurm@22.05.5
          prefix: /usr
        buildable: False
    libevent:
        externals:
        - spec: libevent@2.1.8
          prefix: /usr
        buildable: False
    pmix:
        externals:
        - spec: pmix@4.2.3
          prefix: /usr
        buildable: False
    hwloc:
        externals:
        - spec: hwloc@2.2.0
          prefix: /usr
        buildable: False
EOF

e as seguintes opções foram definidas para os diretórios de cache de compilação,

(access)$ cat << EOF > $SPACK_ROOT/etc/spack/config.yaml
config:
    build_stage:
        - /dev/shm/$user/spack-stage
EOF

para acelerar a compilação usando o sistema de arquivos de ramdisk. Antes de prosseguir para a instalação do OpenFOAM, a versão desejada do Open MPI é instalada com o compilador do sistema:

(compute node)$ spack install -j openmpi@4.0.5 +pmi schedulers=slurm ^pmix@4.2.3 ^hwloc@2.2.0

A distribuição do OpenFOAM é instalada usando o compilador do sistema também. Os componentes disponíveis do OpenFOAM são:

(access node)$ spack list openfoam@2306
...
Variants:
    Name [Default]            When    Allowed values    Description
    ======================    ====    ==============    ==================================================

    build_system [generic]    --      generic           Build systems supported by the package
    int64 [off]               --      on, off           With 64-bit labels
    kahip [off]               --      on, off           With kahip decomposition
    knl [off]                 --      on, off           Use KNL compiler settings
    metis [off]               --      on, off           With metis decomposition
    mgridgen [off]            --      on, off           With mgridgen support
    paraview [off]            --      on, off           Build paraview plugins and runtime post-processing
    precision [dp]            --      sp, dp, spdp      Precision option
    scotch [on]               --      on, off           With scotch/ptscotch decomposition
    source [on]               --      on, off           Install library/application sources and tutorials
    vtk [off]                 --      on, off           With VTK runTimePostProcessing
    zoltan [off]              --      on, off           With zoltan renumbering
...

O OpenFOAM é instalado usando todos os particionadores disponíveis (metis, scotch, zoltan, kahip) e os componentes do gerador de multi-grade (mgridgen, seção 6.3.1.4 da documentação) com o comando:

(compute node)$ spack install -j openfoam@2306 +source precision=dp +metis +scotch +zoltan +kahip +mgridgen ~knl ~int64 ~paraview ^openmpi@4.0.5

No entanto, a instalação resultante está faltando vários componentes. Por exemplo, executando a verificação manual pós-instalação em doc/Build.md,

# Criar o diretório do usuário "run":
mkdir -p "$FOAM_RUN"
# Mudar para o diretório do usuário "run":
run
# Copiar tutorial
cp -r "$FOAM_TUTORIALS"/incompressible/simpleFoam/pitzDaily ./
# Executar o tutorial
( cd pitzDaily && blockMesh && simpleFoam )

tanto o gerador de malha blockMesh quanto o solver simpleFoam estão faltando.

Acontece que o particionador METIS causa falha na instalação de vários componentes. Recompilando apenas com o particionador SCOTCH,

(compute node)$ spack install openfoam@2306 +source +scotch +mgridgen precision=dp ~int64 ~kahip ~knl ~metis ~paraview ~vtk ~zoltan ^openmpi@4.0.5

resolve o problema. Todos os componentes do solver são instalados, mas algumas utilidades ainda estão faltando.

Usamos o seguinte script para detectar todas as utilidades ausentes:

(access node)$ cat list_spack_openfoam
#!/usr/bin/bash

set -euo pipefail

declare variant="${1}" # e.g. @2306%gcc@8.5.0 @2306+mgridgen
declare type="${2}" # solvers, utilities

find_makefile_directories() {
    local directory="${1}"

    find "${directory}" -type d | grep -E '\\/Make$' || true
}

extract_executable_name() {
    local makefile_directory="${1}"

    cat "${makefile_directory}/files" | ( grep -E '^EXE[[:space:]]*=' || true ) | sed 's/^EXE[[:space:]]*=[[:space:]]*\$(FOAM_APPBIN)\///g'
}

main() {
    local variant="${1}"
    local type="${2}"

    local foam_location="$(spack location -i openfoam"${variant}")"

    local pagkage_directory=""
    local executable_name=""
    local installed=""
    local package_makefile_directory=""
    while read -r package_makefile_directory; do
        executable_name=$( extract_executable_name "${package_makefile_directory}" )

        if [ -n "${executable_name}" ]; then
            if [ -x "${foam_location}/platforms/linux64GccDPInt32-spack/bin/${executable_name}" ]; then
                installed="Y"
            else
                installed="N"
            fi
            package_directory="$( echo "${package_makefile_directory}" | xargs -I % dirname % )"

            echo "${installed} : ${executable_name} => ${package_directory#${foam_location}}"
        fi
    done < <( find_makefile_directories "${foam_location}/applications/${type}" )
}

main "${variant}" "${type}"

Uma execução simples do script indica que as seguintes utilidades estão faltando:

(access node)$ ./list_spack_openfoam utilities @2306 | grep -E '^N'
N : addr2line => /applications/utilities/miscellaneous/OSspecific/addr2line
N : foamyHexMeshSurfaceSimplify => /applications/utilities/mesh/generation/foamyMesh/foamyHexMeshSurfaceSimplify
N : foamyHexMeshBackgroundMesh => /applications/utilities/mesh/generation/foamyMesh/foamyHexMeshBackgroundMesh
N : cellSizeAndAlignmentGrid => /applications/utilities/mesh/generation/foamyMesh/cellSizeAndAlignmentGrid
N : foamToCcm => /applications/utilities/mesh/conversion/ccm/foamToCcm
N : ccmToFoam => /applications/utilities/mesh/conversion/ccm/ccmToFoam

É difícil dizer, problemas relacionados ao Markdown geralmente não resultam em 403, mas fornecem algum feedback na interface do usuário para o autor. Nossos erros 403 tendem a estar relacionados à autorização, como postar em uma categoria restrita ou usar uma tag restrita.

Usei seus trechos de texto em uma instância padrão do Discourse e parece estar tudo bem.

Posso sugerir que você verifique com seu moderador para ver se tais restrições estão em vigor?

4 curtidas

Em seguimento a isto, nós quase sempre descobrimos que erros 403 como este ao tentar criar posts (especialmente com blocos de código!) são devido a um WAF excessivamente zeloso acreditando que os blocos de código são shellcode ou um ataque de injeção.

Eu observo que a instância em questão parece ser protegida por um WAF:

○ → host hpc-discourse.uni.lu
hpc-discourse.uni.lu é um alias para fstc-waf2.uni.lu.

e, portanto, suspeito fortemente que os erros 403 não vêm do Discourse, mas do seu WAF.

Inspecionar os cabeçalhos dos erros no navegador deve ser capaz de lhe dizer a origem da rejeição.

7 curtidas

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.