Fehler mit code blocks: 403 Forbidden

Ich habe kürzlich die Verwaltung eines Diskurs-Servers übernommen, und es gibt ein paar Probleme.

  1. Ich habe anhaltende Probleme, wenn ich versuche, einen Beitrag mit Codeblöcken zu erstellen oder zu bearbeiten. Beim Versuch, einen Beitrag mit dem Codeblock zu erstellen oder zu bearbeiten
(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
...

erhalte ich die Fehlermeldung 403 Forbidden.

  1. Markdown unterstützt keine Code-Hervorhebung; das Hinzufügen jeglicher Syntaxspezifikation führt zu einem Fehler 403 Forbidden.

  2. Inline-Code-Segmente verursachen ebenfalls 403 Forbidden an einigen, aber nicht allen Stellen, relativ zu anderen Codeblöcken.

Die installierte Version ist 3.1.1 ( 0612f0d5b6 ).

Hängen diese Probleme zusammen und was könnte dieses Verhalten verursachen?

Beispiel-Beitrag: Compiling OpenFOAM with Spack - 📚 Knowledge nuggets - HPC discourse

Beabsichtigtes Ergebnis:

Es gibt einige Probleme bei der Installation von OpenFOAM von OpenCFD mit Spack.

Es wurde eine Umgebung eingerichtet, um die Pakete mit Spack gemäß der Anleitung im UL HPC-Tutorial zu verwalten. Kurz gesagt, die folgenden Abhängigkeiten wurden für die SPACK-Pakete definiert,

(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

und die folgenden Optionen wurden für die Build-Cache-Verzeichnisse definiert,

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

um die Kompilierung mithilfe des Ramdisk-Dateisystems zu beschleunigen. Bevor mit der Installation von OpenFOAM fortgefahren wird, wird die gewünschte Version von Open MPI mit dem Systemcompiler installiert:

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

Die Distribution von OpenFOAM wird ebenfalls mit dem Systemcompiler installiert. Die verfügbaren Komponenten von OpenFOAM sind:

(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
...

OpenFOAM wird unter Verwendung aller verfügbaren Partitionierer (metis, scotch, zoltan, kahip) und der Multi-Grid-Generator-Komponenten (mgridgen, Abschnitt 6.3.1.4 der Dokumentation) mit dem Befehl installiert:

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

Die resultierende Installation weist jedoch mehrere fehlende Komponenten auf. Beispielsweise schlagen bei der Ausführung der manuellen Post-Installationsprüfung in doc/Build.md,

# Erstellen Sie das Benutzerverzeichnis "run":
mkdir -p "$FOAM_RUN"
# Wechseln Sie in das Benutzerverzeichnis "run":
run
# Kopieren Sie das Tutorial
cp -r "$FOAM_TUTORIALS"/incompressible/simpleFoam/pitzDaily ./
# Führen Sie das Tutorial aus
( cd pitzDaily && blockMesh && simpleFoam )

sowohl der Mesh-Generator blockMesh als auch der Solver simpleFoam fehl.

Es stellt sich heraus, dass der METIS-Partitionierer dazu führt, dass die Installation mehrerer Komponenten fehlschlägt. Eine Neukompilierung nur mit dem SCOTCH-Partitionierer,

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

löst das Problem. Alle Solver-Komponenten sind installiert, aber einige Dienstprogramme fehlen immer noch.

Wir verwenden das folgende Skript, um alle fehlenden Komponenten zu erkennen:

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

set -euo pipefail

declare variant="${1}" # z.B. @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}"

Eine einfache Ausführung des Skripts zeigt, dass die folgenden Dienstprogramme fehlen:

(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

Es ist schwer zu sagen, Markdown-bezogene Probleme sind normalerweise keine 403er, sondern geben dem Autor ein gewisses UI-Feedback. Unsere 403-Fehler beziehen sich eher auf die Autorisierung, z. B. das Posten in einer eingeschränkten Kategorie oder die Verwendung eines eingeschränkten Tags.

Ich habe Ihre Textblöcke in einer Standardinstanz von Discourse verwendet und es scheint in Ordnung zu sein.

Könnte ich vorschlagen, dass Sie sich mit Ihrem Moderator in Verbindung setzen, um zu sehen, ob solche Einschränkungen bestehen?

4 „Gefällt mir“

Darüber hinaus stellen wir fast immer fest, dass 403-Fehler wie dieser beim Versuch, Beiträge zu erstellen (insbesondere mit Codeblöcken!), auf eine übereifrige WAF zurückzuführen sind, die den Codeblock für Shellcode oder einen Injection-Angriff hält.

Ich stelle fest, dass die betreffende Instanz von einer WAF bedient wird:

○ → host hpc-discourse.uni.lu
hpc-discourse.uni.lu ist ein Alias für fstc-waf2.uni.lu.

Daher vermute ich stark, dass die 403-Fehler nicht von Discourse, sondern von Ihrer WAF stammen.

Die Untersuchung der Header der Fehler im Browser sollte Ihnen die Quelle der Ablehnung verraten können.

7 „Gefällt mir“

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