Perguntas Frequentes
Sim, o Dataverse trabalha com uma estrutura de indicadores persistentes para publicação de dados.
Sim, o Dataverse faz um controle dos dados postados, gerando um sub-identificador para cada versão postada. Todas as versões postadas são disponibilizadas.
Não. Dados embargados podem ser carregados para o Dataverse, mas não devem ser publicados, além disso, o acesso restrito deve ser aplicado à cada usuário ou grupo de usuários que tenham privilégios para acessá-los. A funcionalidade nativa para publicação de dados embargados está prevista para versões futuras.
Sim, se existir esse perfil de usuário configurado em uma comunidade de dados (dataverses). Diferentes perfis e permissões específicas como “publicar dados” podem ser atribuídos a usuários de forma que consiga executar a ação.
Não. Apenas se o administrador do servidor Dataverse executar um comando, programaticamente por meio de APIs (Application Program Interfaces).
O limite é imposto pela configuração definida para tamanho de arquivos a serem enviados. Esse limite pode ser reconfigurado toda vez que necessário. Vale ressaltar que a qualidade de conexão para o envio dos arquivos também é um critério a ser considerado, visto que, caso a conexão seja interrompida, o envio de arquivos é cancelado.
Sim, o Dataverse foi projetado para utilização de APIs como uma das formas de envio de dados, além de poder executar outras funções, como: criação, envio, publicação e modificação de dataverses e datasets, todas programaticamente.
Criar, visualizar, excluir, exibir conteúdo e tamanho; listar, criar, excluir e atribuir papéis a usuários; listar e definir metadados; criar ou importar datasets; e publicar.
Recuperar a representação em JSON; listar e recuperar versões; listar, editar, excluir e exportar metadados; listar arquivos; publicar; excluir rascunho; alterar a data da criação; listar, criar e atribuir papéis a usuários; criar, excluir e recuperar URL privada; adicionar arquivos; reportar o tamanho; submeter para revisão; recuperar o autor; recuperar métricas como quantidade de visualizações e downloads; e excluir.
Todos os principais recursos que podem ser executados programaticamente via APIs nativas do Dataverse podem ser consultados em http://guides.dataverse.org/en/latest/api/native-api.html.
No momento da escrita desta FAQ, as principais operações que não estavam disponíveis via AP estão listadas abaixo. Mais informações em: http://guides.dataverse.org/en/latest/api/faq.html#what-functionality-is-gui-only-and-not-available-via-api
- Definir uma imagem de logotipo, URL e tagline ao criar uma comunidade de dados;
- Editar propriedades de uma comunidade de dados existente;
- Ativar solicitação de acesso para os termos de uso;
- Fazer download de um guestbook;
- Definir guestbook_id para um conjunto de dados;
- Preencher um guestbook;
- Visualizar por que motivo uma ingestão de arquivo falhou;
Realize um undeploy do Dataverse, e reinstale com o deploy.
- /glassfish4/bin/asadmin list-applications
- /glassfish4/bin/asadmin undeploy dataverse
- /glassfish4/bin/asadmin deploy dataverse.war
Antes de realizar os testes com o Dataverse verifique se o Handle está funcionando pelo Batch, informações para teste estão disponível em: https://dadosdepesquisa.rnp.br/wiki/index.php/RDPBrasil/Handle.Net/S02
Verifique se foi realizado o pagamento anual da Taxa do Handle em http://handle.net/ ou pelo e-mail [email protected]
Verifique se o serviço do Handle está ativado, e também se as portas 8000 e 2641 estão abertas para acesso externo.
- $ service handle status
Os arquivos de atualização e os procedimentos para cada atualização estão disponíveis em: https://github.com/IQSS/dataverse/releases
PS: Caso precise atualizar mais de uma versão (ex: da 4.16 para 4.20) execute todos os procedimentos para as versões 4.17, 4.18, 4.18.1, 4.19 e 4.20.
Verificar a sessão Configuração do Apache Proxy para revisar os passos realizados.
Para ativar a limpeza do índice e reindexação e necessário acessar o servidor via bash e executar os comandos:
- curl http://localhost:8080/api/admin/index/clear
-
Verificar o nome da aplicação:
# /usr/local/glassfish4/bin/asadmin list-applications
Desinstalar o Dataverse:
# /usr/local/glassfish4/bin/asadmin undeploy dataverse[-versão]
Parar o Glassfish:
# /usr/local/glassfish4/bin/asadmin stop-domain domain1
Apagar o banco de dados:
# psql -U postgres postgres=# drop database dnvdb; postgres=# \q
Remover o diretório domain1 do Glassfish
rm /usr/local/glassfish4/glassfish/domains/domain1/
Confira se o serviço Apache está rodando corretamente através do comando:
sudo systemctl status httpd
Revise as configurações de redirecionamento em /etc/httpd.
Outra configuração importante é habilitar o AJP (Apache Jserve Proxy) no Apache, revise se você adicionou o trecho abaixo no arquivo de configuração de SSL antes de .
# don't pass paths used by rApache and TwoRavens to Glassfish
ProxyPassMatch ^/RApacheInfo$ !
ProxyPassMatch ^/custom !
ProxyPassMatch ^/dataexplore !
# don't pass paths used by Shibboleth to Glassfish
ProxyPassMatch ^/Shibboleth.sso !
ProxyPassMatch ^/shibboleth-ds !
# pass everything else to Glassfish
ProxyPass / ajp://localhost:8009/
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
Crie um arquivo shibAuthProviders.json com as informações abaixo:
E configure o Dataverse para exibir o botão de login através da API:
Verifique se o serviço do Shibboleth está rodando através do comando:
$ sudo systemctl status shibd
E revise no arquivo de configuração /var/shibboleth/shibboleth2.xml se o endereço do discovery está correto na propriedade discoveryURL.
Erro de serviço não registrado, exemplo:
WEB LOGIN SERVICE - UNSUPPORTED REQUEST
The application you have accessed is not registered for use with this service.
Entre em contato com a gestora da federação e envie o arquivo https://__SEUDOMINIO__/Shibboleth.sso/Metadata para refazer a relação de confiança do seu serviço com o provedor de identidade que está sendo utilizado para autenticação. Qualquer modificação na configuração do Shibboleth, esse procedimento deve ser realizado novamente pois o arquivo Metadata é alterado.
Erro de recurso não disponível, exemplo:
HTTP Status 404 - /idp/profile/SAML2/Redirect/SSO
type Status report
message /idp/profile/SAML2/Redirect/SSO
description The requested resource is not available.
Confira se o provedor de identidade que você está tentando autenticar está disponível, provável que ele não esteja.
Confira a permissão dos certificados utilizados pelo Shibboleth localizados na pasta /var/shibboleth/. Eles são utilizados para garantir a relação de confiança entre o serviço e o provedor de identidade autenticado e precisam estar acessíveis pelo serviço shibd. Recomenda-se utilizar a ferramenta keygen.sh para gerar esses certificados.
$ ls -la /var/shibboleth/*.pem
Caso necessário, realize as alterações de propriedades nos certificados.
$ sudo chown _shibd:_shibd /var/shibboleth/*.pem $ sudo chmod 600 /var/shibboleth/*.pem
Se você estiver recebendo o erro NET::ERR_CERT_AUTHORITY_INVALID em navegadores Chromium, significa que há um problema com a autoridade de certificação que emitiu o certificado SSL. Revise a validade dos certificados utilizados na configuração do Apache. Caso você gerou um certificado novo durante a configuração, considere alterar para um certificado criado por uma autoridade de certificação.
Last modified 3yr ago