Obrigado pelas informações valiosas!

Tenho outra pergunta, sobre a consulta SQL que seleciona os usuários do vBulletin.

Quando importei meu antigo fórum phpBB para o Discourse há 3 anos, havia cerca de 20.000 usuários. Obviamente, a maioria eram contas inativas. Durante esses 3 anos, o Discourse fez sua própria limpeza de usuários inativos, e agora temos um número mais realista de 3.000 membros.

Quando importei meus 180.000 usuários do vBulletin e pedi ao Discourse que realizasse sua tarefa de limpeza de forma agressiva, fiquei com 27.000 usuários, o que parece justo.

No meu vBulletin, desde que:

1. Todas as mensagens postadas por usuários em perfis de outros usuários foram importadas para o Discourse como tópicos sem categoria e sem título, que não agregam nada além de ruído inútil, e
2. A grande maioria dos usuários que postaram apenas em perfis de outros usuários parece ser de spammers,
   Gostaria de fazer a limpeza durante a importação, e não depois.

Não entendo todo o banco de dados do vBulletin, que é um pouco confuso com a questão dos nós, mas gostaria de importar apenas usuários que tenham postado pelo menos 1 tópico ou resposta.
Parece-me que tópicos e respostas preenchem o campo lastpostid na tabela de usuários do vBulletin, mas postagens públicas de perfil não.

Sim, pretendo editar

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

para:

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email, u.lastpost
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
    WHERE u.lastpost > 0
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

Apenas adicionei um WHERE u.lastpost > 0.

Uma contagem com essa consulta me dá 25.000 usuários, comparado aos 27.000 usuários ativos na minha importação anterior, após uma limpeza do Discourse, mas ainda com esses tópicos sem título (antigas mensagens públicas de perfil). Isso significaria que cerca de 2.000 usuários teriam postado apenas em perfis de outros usuários, o que não é um número absurdo.

Você acha que meu raciocínio está correto e que adicionar WHERE u.lastpost > 0 limpará bem minha base de usuários sem causar nenhum efeito prejudicial?

Isso depende de onde seu banco de dados esteve. Se ele foi migrado do phpBB para o vBulletin ou se passou por várias atualizações do vBulletin, então esse raciocínio pode estar errado.

O melhor que você pode fazer é verificar seu raciocínio executando mais consultas, por exemplo, listando todas as postagens feitas por usuários sem um lastpost.

Além disso, se você tiver plugins como “likes” ou “votação”, pode acabar removendo usuários que não deveria remover.

Minha estratégia é ser muito conservador ao remover ou deixar de fora coisas. Armazenamento é barato.

Obrigado, farei como você disse; prefiro ser cauteloso.
Vou deixar o Discourse fazer sua própria limpeza ao longo do tempo.

Tenho adicionado expressões regulares personalizadas para limpeza de posts no seu script de migração há dias, pois o fórum é muito antigo e foi migrado do phpBB antes do vBulletin, então muitas coisas precisaram ser tratadas. Mas acho e espero estar perto de finalizar tudo.

Não conheço muito bem o vBulletin, mas o fórum em que estou trabalhando usava o vBulletin 5.6, e algumas imagens externas que publiquei nele usavam esta sintaxe no banco de dados do vBulletin:
[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/forum.monocycle.info\/uploads\/default\/original\/2X\/3\/396192845ba93e7df2a6109a2608072efa21ee32.jpeg"}[/IMG2]
Não tenho certeza se isso foi “esquecido” no seu script ou se o administrador do fórum usou algum plugin que gerava essas tags img2.

De qualquer forma, corrigi isso com este código:

    raw = raw.gsub(/\[img2=json\].+?(http.+?).}\[\/img2\]/i) {"\n#{$1}\n"}

Tenho uma pergunta, porém: o Discourse reprocessará automaticamente os posts importados ao longo do tempo? Se sim, ele começará pelos posts mais recentes?

Olá novamente,
Meu fórum tem cerca de 1000 tags, mas provavelmente não as usaremos no Discourse. Além disso, essas tags devem ser uma bagunça. Posso apenas comentar esta linha no importador:

    import_tags

Ou isso pode causar algum dano colateral?

Você pode comentá-lo com segurança.

É seguro não esperar que Sidekiq termine seus trabalhos após importar algo?

Importei meus usuários e este é o estado atual do Sidekiq.

image1182×324 27.3 KB

O que acontece com essas tarefas se eu criar um backup e restaurá-lo em um fórum de produção?

Não, embora uma recriação completa (rebake) possa recriar a maioria desses trabalhos, recomendo absolutamente que você aguarde.

Elas continuarão sendo executadas… na instância de importação.
Elas não serão incluídas no backup nem transferidas para o fórum de produção.

Obrigado!

Devido a algumas mensagens de erro durante a restauração de backups (que não impedem a conclusão da restauração nem o funcionamento do fórum), eu estava me perguntando se poderia ser porque eu não esperei o Sidekiq terminar seu trabalho.

Iniciei uma nova importação do vBulletin: importei apenas grupos e 30.000 usuários no meu Discourse de desenvolvimento, esperei algumas dezenas de minutos, criei um backup e restaurei o backup em uma instalação baseada em Docker. A restauração funcionou, mas os logs mostram esses erros:

ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "users" does not exist LINE 1: SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 ^ ) lib/a
10:03 pm
7
ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "user_auth_tokens" does not exist LINE 1: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((...

Eles são inconsistentes, e os erros de relação diferem de um backup para outro.
Não consigo entender de onde vêm esses erros.

TL;DR: Acredito que esses erros não tenham relação alguma com a importação.

Já vi isso antes. Acredito que seja uma condição de corrida que ocorre porque o banco de dados está sendo acessado enquanto o backup está sendo restaurado.

Isso pode ser causado por tráfego regular chegando ao seu servidor ou por um processo Sidekiq que não foi pausado. Em ambos os casos, é inofensivo. Se eu fosse você, ignoraria completamente todos os erros do PostgreSQL que ocorrerem antes do término completo da restauração.

Isso é tranquilizador!

O problema é que não só as mensagens em si me assustam um pouco, mas também porque:

1. Elas ocorrem em todos (ou quase? ) os backups que criei desde que iniciei minha importação, seja eu restaurando o backup em um fórum de desenvolvimento local ou em uma instalação online via Docker.
2. Elas impedem que o log de restauração (na interface de backup do Discourse) continue sendo registrado na interface do Discourse enquanto a restauração está em andamento: ele fica preso em “descompactando arquivo” (ou “Criando funções ausentes no esquema discourse_functions…” se for um backup sem uploads).
   Parece que algo travou, mas se eu aguardar, depois de um tempo sempre sou desconectado automaticamente e, ao fazer login novamente, a importação parece ter funcionado bem, apesar dessas mensagens de erro.

Como o fórum está funcionando (exceto pela edição de categorias que resulta em um erro 502, que descrevi em outro tópico), estou apenas com medo de que o fórum funcione… Até que, por algum motivo, pare de funcionar daqui a algumas semanas/meses/anos devido a algo que não identifiquei antes, o que realmente não quero que aconteça, especialmente porque tenho trabalhado nessa importação todos os dias há 1 mês e contando.

De qualquer forma, obrigado pela ajuda, é muito apreciada. Estou colocando muita energia nesse trabalho de importação não remunerado para uma grande comunidade, e ter pessoas respondendo às minhas perguntas é sempre um alívio.

Primeiramente, obrigado por postar isso. Acabei de tentar importar o vBulletin 3.7.x. Segui todos os passos, mas ao executar o script de importação, ele diz que não consegue conectar, mesmo eu conseguindo conectar. Alguma ideia?

root@uat-app:/var/www/discourse# export DB_NAME="vb4"
root@uat-app:/var/www/discourse# export DB_USER="root"
root@uat-app:/var/www/discourse# export DB_PW="1234"
root@uat-app:/var/www/discourse# export TABLE_PREFIX="vbulletin"
root@uat-app:/var/www/discourse# export ATTACHMENT_DIR='/shared/vbulletin'
root@uat-app:/var/www/discourse# export TIMEZONE="America/Vancouver"
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost quer vb4
Carregando grupos existentes...
Carregando usuários existentes...
Carregando categorias existentes...
Carregando posts existentes...
Carregando tópicos existentes...
==================================================
Acesso negado para o usuário 'root'@'localhost'
Não foi possível conectar ao banco de dados.

Hostname: localhost
Username: root
Password: 1234
database: vb4

Edite o script ou defina estas variáveis de ambiente:

export DB_HOST="localhost"
export DB_NAME="vbulletin"
export DB_PW=""
export DB_USER="root"
export TABLE_PREFIX="vb_"
export ATTACHMENT_DIR '/path/to/your/attachment/folder'

Saindo.

Abaixo, você pode ver que consigo fazer login no banco de dados usando as mesmas credenciais e validei o nome do banco de dados e o prefixo da tabela.

root@uat-app:/var/www/discourse# mysql -uroot -p1234 -hlocalhost
Bem-vindo ao monitor MariaDB. Os comandos terminam com ; ou \g.
Seu ID de conexão MariaDB é 70
Versão do servidor: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab e outros.

Digite 'help;' ou '\h' para ajuda. Digite '\c' para limpar a instrução de entrada atual.

MariaDB [(none)]> use vb4;
Lendo informações da tabela para conclusão dos nomes de tabela e coluna
Você pode desativar esse recurso para obter uma inicialização mais rápida com -A

Banco de dados alterado
MariaDB [vb4]> select * from information_schema.tables where table_schema = 'vb4' and table_name = 'vbulletinpost'
    -> ;
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME    | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME         | UPDATE_TIME         | CHECK_TIME          | TABLE_COLLATION   | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT | MAX_INDEX_LENGTH   | TEMPORARY |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| def           | vb4          | vbulletinpost | BASE TABLE | MyISAM |      10 | Dynamic    |    1037509 |            356 |   370191960 | 281474976710655 |     53087232 |         0 |        1046506 | 2020-11-14 14:27:01 | 2020-11-14 14:27:28 | 2020-11-14 14:27:32 | latin1_swedish_ci |     NULL |                |               | 288230376151710720 | N         |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
1 linha no conjunto (0,001 seg)

MariaDB [vb4]>

Além disso, exportei os avatares para /admincp/avatar.php?do=storage e exportei os avatares para três pastas diferentes, assim:

/shared/vbulletin/signaturepics/
/shared/vbulletin/customprofilepics/
/shared/vbulletin/customavatars/

Devo então especificar a pasta pai assim? Ou preciso pegar o conteúdo das três pastas e colocá-los em uma só?

export ATTACHMENT_DIR='/shared/vbulletin'

Minha única suposição é que talvez sua senha tenha caracteres estranhos nela?

Na verdade, não passa de caracteres alfanuméricos. De qualquer forma, tentei novamente e confirmei que não funciona até que eu defina explicitamente a senha. Também notei que as instruções precisam ser atualizadas, então estou colando aqui o que funcionou para mim.

As instruções precisam ser atualizadas. Aqui está o que funciona para mim a partir de novembro de 2020. Note que é realmente melhor executar esta importação usando screen, pois a importação levará horas, e usar nohup provavelmente não será útil, pois o script de importação estará constantemente atualizando o número de cada item importado, o que provavelmente tornará o arquivo stdout muito grande.

Instalar Banco de Dados para Hospedar Dados do vBulletin

Baixar os Pacotes Mais Recentes

Observe que o MySQL não está mais disponível, a menos que o repositório do Oracle MySQL seja adicionado explicitamente à lista de repositórios. O MariaDB substituiu o MySQL.

root@uat-app:~# apt-get update
root@uat-app:~# apt-get install libmariadb-dev
root@uat-app:~# apt-get install default-mysql-server

Iniciar o Banco de Dados

root@uat-app:~# service mysql status
[info] MariaDB está parado..
root@uat-app:~#
root@uat-app:~# service mysql start
[ ok ] Iniciando servidor de banco de dados MariaDB: mysqld.
root@uat-app:~# service mysql status
[info] /usr/bin/mysqladmin Versão 9.1 Distribuição 10.3.25-MariaDB, para debian-linux-gnu em x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab e outros.

Versão do servidor 10.3.25-MariaDB-0+deb10u1
Versão do protocolo 10
Conexão Localhost via socket UNIX
Socket UNIX /var/run/mysqld/mysqld.sock
Tempo de atividade: 4 segundos

Threads: 7 Perguntas: 461 Consultas lentas: 0 Aberturas: 177 Limpeza de tabelas: 1 Tabelas abertas: 31 Consultas por segundo média: 115.250.

Instalar Gems para Conectividade ao Banco de Dados

O seguinte mostra que o ‘bundle’ mais recente não gosta de algumas das flags nas instruções originais e há necessidade de desativar o modo ‘deployment’.

root@uat-app:~# echo "gem 'mysql2', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# echo "gem 'php_serialize', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle install --no-deployment --without test --without development --path vendor/bundle'
[DEPRECATED] A flag `--path` está obsoleta porque depende de ser lembrada entre as chamadas do bundler, o que o bundler não fará mais em versões futuras. Em vez disso, use `bundle config set path 'vendor/bundle'` e pare de usar esta flag.
[DEPRECATED] A flag `--without` está obsoleta porque depende de ser lembrada entre as chamadas do bundler, o que o bundler não fará mais em versões futuras. Em vez disso, use `bundle config set without 'development'` e pare de usar esta flag.
Você está tentando instalar em modo de implantação após alterar
seu Gemfile. Execute `bundle install` em outro lugar e adicione o
Gemfile.lock atualizado ao controle de versão.

Se esta for uma máquina de desenvolvimento, remova o congelamento do /var/www/discourse/Gemfile executando `bundle config unset deployment`.

As dependências no seu gemfile mudaram

Você adicionou ao Gemfile:
* mysql2
* php_serialize

Atualizar Configuração e Reexecutar Instalação

Verificar por CLI

A verificação da configuração confirmou que está definida para o modo ‘deployment’.

root@uat-app:/var/www/discourse# bundle config list
As configurações estão listadas em ordem de prioridade. O valor superior será usado.
deployment
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): true

jobs
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): 4

retry
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): 3

path
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): "vendor/bundle"

without
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): [:development, :test]

Verificar Inspecionando o Arquivo de Configuração

O seguinte faz a mesma verificação inspecionando o arquivo de configuração.

root@uat-app:/var/www/discourse# cat /var/www/discourse/.bundle/config
---
BUNDLE_DEPLOYMENT: "true"
BUNDLE_JOBS: "4"
BUNDLE_RETRY: "3"
BUNDLE_PATH: "vendor/bundle"
BUNDLE_WITHOUT: "development:test"

Atualizar Configuração

root@uat-app:/var/www/discourse# bundle config set path 'vendor/bundle'
Seu aplicativo definiu o path para "vendor/bundle". Isso substituirá o valor global que você está definindo atualmente.
root@uat-app:/var/www/discourse# bundle config set without 'development:test'
Seu aplicativo definiu o without para "development:test". Isso substituirá o valor global que você está definindo atualmente.
root@uat-app:/var/www/discourse# bundle config unset deployment

Validar Configuração Novamente

root@uat-app:/var/www/discourse# bundle config list
As configurações estão listadas em ordem de prioridade. O valor superior será usado.
path
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): "vendor/bundle"
Definido para o usuário atual (/root/.bundle/config): "vendor/bundle"

without
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): [:development, :test]
Definido para o usuário atual (/root/.bundle/config): [:development, :test]

jobs
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): 4

retry
Definido para seu aplicativo local (/var/www/discourse/.bundle/config): 3

Tentar Instalação Novamente

Execute a instalação novamente para as Gems e saia do contêiner.

root@uat-app:/var/www/discourse# su discourse -c 'bundle install'
...........
Bundle completo! 125 dependências do Gemfile, 163 gems agora instaladas.
Gems nos grupos development e test não foram instalados.
Gems empacotadas estão instaladas em `./vendor/bundle`
root@uat-app:/var/www/discourse# exit

Criar Diretório para Dados do vBulletin

Criar Diretório

[root@uat standalone]# pwd
/var/discourse/shared/standalone
[root@uat standalone]# mkdir vbulletin

Copiar Banco de Dados do vBulletin

[root@uat standalone]# scp <login user>@<vbulletin server IP>:/home/backup/vbulletin/vbulletin-2020-11-14-03:30:01.sql.bz2 ./vbulletin/.

Descompactar Banco de Dados do vBulletin

[root@uat containers]# docker exec -it app bash
root@uat-app:/# cd /shared/vbulletin
root@uat-app:/shared/vbulletin# bunzip2 vbulletin-2020-11-14-03\:30\:01.sql.bz2

Configurar Fonte de Dados

Criar Banco de Dados vb4

root@uat-app:/shared/vbulletin# mysql -uroot -p -e 'CREATE DATABASE vb4'
Digite a senha:

Importar vBulletin para MariaDB

root@uat-app:/shared/vbulletin# mysql -uroot -p vb4 < vbulletin-2020-11-14-03\:30\:01.sql
Digite a senha:

Descompactar Arquivos de Perfil

[root@uat vbulletin]# tar xvfz signaturepics.tar.gz
[root@uat vbulletin]# tar xvfz customavatars.tar.gz
[root@uat vbulletin]# tar xvfz customprofilepics.tar.gz

Atualizar Senha Raiz do Banco de Dados

root@uat-app:/var/www/discourse# mysql -uroot -p
Digite a senha:
Bem-vindo ao monitor MariaDB. Os comandos terminam com ; ou \g.
Seu ID de conexão MariaDB é 77
Versão do servidor: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab e outros.

Digite 'help;' ou '\h' para ajuda. Digite '\c' para limpar a declaração de entrada atual.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
Query OK, 0 linhas afetadas (0.001 seg)

MariaDB [(none)]> quit
Adeus

Importar para o Discourse

Definir Detalhes de Conexão da Fonte de Dados

[root@uat vbulletin]# export DB_NAME="vb4"
[root@uat vbulletin]# export DB_USER="root"
[root@uat vbulletin]# export DB_PW="1234"
[root@uat vbulletin]# export TABLE_PREFIX="vbulletin"
[root@uat vbulletin]# export ATTACHMENT_DIR='/shared/vbulletin'
[root@uat vbulletin]# export TIMEZONE="America/Vancouver"
[root@uat vbulletin]# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost quer vb4
Carregando grupos existentes...
Carregando usuários existentes...
Carregando categorias existentes...
Carregando posts existentes...
Carregando tópicos existentes...

importando grupos...
15 / 15 (100.0%) [3272 itens/min] n]
importando usuários
117 / 11033 ( 1.1%) [145 itens/min] in]

Então, o problema com sua conexão inicial ao banco de dados era a mistura de bibliotecas?

Eu não acho que seja isso. Eu literalmente acabei de alterar a senha explicitamente e ela conseguiu executar. Estou tendo um problema ao importar mensagens privadas agora. Estou vendo muito do seguinte. Alguma ideia do que seja isso?

importando mensagens privadas...
      139 / 177409 (  0.1%)  [399 itens/min]  um dos IDs dos participantes é nil -- [nil, 270]
pm-149 não tem destino (a:1:{i:486;s:5:"TonyN";})
      364 / 177409 (  0.2%)  [418 itens/min]  um dos IDs dos participantes é nil -- [nil, 276]
pm-420 não tem destino (a:1:{i:623;s:14:"the other side";})
      571 / 177409 (  0.3%)  [414 itens/min]  um dos IDs dos participantes é nil -- [nil, 445]
pm-702 não tem destino (a:1:{i:767;s:6:"greatg";})
      572 / 177409 (  0.3%)  [414 itens/min]  um dos IDs dos participantes é nil -- [nil, 445]
      605 / 177409 (  0.3%)  [416 itens/min]  um dos IDs dos participantes é nil -- [nil, 461]

Ou esses usuários não foram importados por algum motivo (falta de endereço de e-mail era uma causa, mas isso já deve ter sido resolvido), ou, por algum outro motivo, o código que consulta os nomes de usuários importados não está funcionando (talvez a capitalização do nome de usuário?).

@pfaffman Sim, parece mesmo, embora alguns detalhes não estejam claros. Vamos analisar o primeiro, por exemplo.

1. O que significa pm-149?
2. Para a:1:{i:486;s:5:"TonyN";}, o texto “TonyN” parece ser o nome de usuário, mas e os outros números?
3. E quanto a [nil, 270]? O que significa 270?

Se eu conseguir entender o que está causando o erro, pelo menos poderei consultar o banco de dados para verificar se há algum problema nos dados. Mas não tenho certeza do que esses valores realmente significam.

Aliás, também notei que todos os fóruns importados têm permissão para todos. Isso significa que os fóruns que deveriam ser acessíveis apenas aos moderadores foram configurados como visíveis para todos. Existe alguma forma de controlar isso?

Desculpe. Não me lembro bem o suficiente para explicar. É tudo o que tenho a oferecer de ajuda gratuita sobre isso.

Claro. Veja Understanding groups and category permissions

Alguns importadores se esforçam para importar grupos, mas poucos sabem como aplicar essas permissões às categorias que são importadas. Você precisará corrigi-las manualmente.

Seguindo as instruções de @titus, parece que estou tendo problemas ao importar o banco de dados…

root@DO-Discourse-app:/shared/vbulletin# mysql -uroot -p vb4 < CC12-Sat-Full-Backup.sql
Digite a senha:
ERRO 1265 (01000) na linha 4928: Dados truncados para a coluna 'method' na linha 1
root@DO-Discourse-app:/shared/vbulletin#

Alguma sugestão sobre o que ele está procurando?

N/M São erros no banco de dados original…