Cds invenio

CDS INVENIO
DÍA 1: INTRODUCCIÓN

Miguel Martín González - miguelm@unizar.es

Del lat.: repositorium, significa
REPOSITORIOS: ¿qué son? armario, alacena, “lugar donde se
guarda algo” [RAE]

SERVICIOS
A university-based institutional repository is a set of
FUNCIONES
services that a university offers to the members of its
community for the management and dissemination of
digital materials created by the institution and its
community members. It is most essentially an
organizational commitment to the stewardship of these
digital materials, including longterm
preservation where appropriate, as well as organization
and access or distribution
[Clifford A. Lynch (2003). Institutional Repositories: Essential Infrastructure for
Scholarship in the Digital Age. ARL Bimonthly OBJETOS
Report 226. http://www.arl.org/newsltr/226/ir.html]
DIGITALES

Archivar (depósito)

Preservar (METS,
PREMIS)

Difundir (OAI-PMH) INSTITUCIONES
PERSONAS

Partes básicas: Conceptos y glosario

Portalboxes (información
Regular collections Virtual collections (otra
adicional)
(asociado a doctype) forma de organizar
contenido)

CDS INVENIO
DÍA 2: ESTRUCTURA GENERAL DE
FUNCIONAMIENTO Y EXPLICACIÓN DE
MÓDULOS


http://invenio-
demo.cern.ch/help/hacking/modules-

ENVIO DE DOCUMENTOS: Flujo general

Operaciones realizadas en el servidor Interfaz de usuario
(privilegiadas) (loggeado)

ENVIO DE DOCUMENTOS: Envío mediante menú (como USUARIO
loggeado) 1de2 WebSubmit is a comprehensive submission system allowing
authorized individuals (authors, secretaries and repository
maintenance staff) to submit individual documents into the
system. The submission system disposes of a flow-control
mechanism that assures the data approval by authorized units.
In total there are several different exploitable submission
schemas at a disposal, including an automated full text
document conversion from various textual and image formats.
This module also disposes of information extraction
functionality, focusing on bibliographic entities such as
references, authors, keywords or other implicit metadata.

Caso más simple: envío autorizado a TODO usuario que se valide correctamente
(sin moderación). Por ejemplo TRABAJOS ACADÉMICOS.

Login en el sistema (utilizando
los datos del correo-e)

[WEBACCESS]

Menú: Enviar 
elección del tipo de documento
(doctype)

[WEBSUBMIT]

loggeado) 2de2

loggeado) 2de2 Guarda
temporalmente el
envío (accesible más
tarde mediante el menú
“Sus Opciones  Sus
envíos”).
NO SE COMPLETA EL
ENVIO.
Termina el envío (manda,
si procede, email a los
moderadores de contenido
asi como al autor,
informando del envío
completado).

NO aparece
inmediatamente el registro
en el Repositorio
(hay que ejecutar
manualmente las tareas
de BibSched o esperar un
tiempo prudencial –máx
1h- a que se ejecuten
automáticamente).
Este número (conocido como access) es interesante para RESOLVER PROBLEMAS en el envío de los registros.

DURANTE el envío:
[root@aneto cdsadmin]# find /soft -name “*1273473021_16130*"
/soft/cds-invenio/var/data/submit/storage/running/TAZ/1273473021_16130

AL FINAL del envío (después de pulsar “Terminar envío”):ç
[root@aneto cdsadmin]# grep -R "TAZ-TFM-2010-018" /soft/cds-invenio/var/
Binary file /soft/cds-invenio/var/data/submit/storage/done/running/TAZ/TAZ-TFM-2010-018_20100510121914.tar.gz
matches

ENVIO DE DOCUMENTOS: RECEPCIÓN DE CORREO
ELECTRÓNICO
El usuario (submitter) y el administrador del Repositorio reciben un email indicando que el envío se ha
completado:

Este enlace indica que record number se asigna(rá) al nuevo registro.

ENVIO DE DOCUMENTOS: Flujo general

Parte ya Una vez que el usuario ha pulsado “Terminar
explicada
envío” se realizan automáticamente las
tareas explicadas hasta ahora.

Al observar Bibsched aparecerán nuevas
Procesos tareas de “BibUpload”. Ayuda sobre
internos BibUpload:
(bibsched)
http://zaguan.unizar.es/help/admin/bibupload-admin-guide

Tras ser ejecutadas las correspondientes
tareas de BibUpload, se realiza la indexación
del nuevo registro (BibIndex) y éste aparece
en zaguan (WebColl):

http://zaguan.unizar.es/record/XXXX

BIBSCHED: Qué es y cómo funciona http://zaguan.unizar.es/help/admin/howto-run
Observar el scheduler (programador) de tareas:
[root@aneto cdsadmin]# sudo -u apache bibsched

Puede funcionar en modo automático o manual (conmutable pulsando “A”). Cuando está en modo manual podemos
desplazarnos por las tareas (flechas arriba/abajo) y ejecutar una tarea en concreto (estando sobre ella, pusar “R”). En automático
(estado normal) las tareas se ejecutan solas cada cierto tiempo. Pulsando “L” sobre una tarea vemos el LOG (registro de
eventos) de la misma.

BIBINDEX, BIBFORMAT, WEBCOLL, (WEBSEARCH, BIBRANK)

BIBINDEX: Se encarga de la
indexación de los datos del registro
(modifica las BD‟s para que podamos
encontrar ese registro cuando lo
busquemos)
http://zaguan.unizar.es/help/admin/bibindex-admin-guide

BIBFORMAT: Se encarga de
formatear los registros y almacenar ese
formateo en BD (si formato cacheado).
http://zaguan.unizar.es/help/admin/bibformat-admin-guide

WEBCOLL: Se encarga de
“aglutinar” registros en Colecciones.
http://zaguan.unizar.es/help/admin/howto-run
$ webcoll -v0 -s1h

Las colecciones se definen utilizando el
módulo WEBSEARCH.

[AVANZADO]
BIBRANK: Se encarga de otorgar “importancia” a los
registros. Se ejecuta periódicamente sobre todos los registros.
Tiene en cuenta diversos criterios.

BIBINDEX: gestión de índices
http://zaguan.unizar.es/help/admin/bibindex-admin-guide

Manage indexes (gestionar índices): http://zaguan.unizar.es/admin/bibindex/bibindexadmin.py
Manage logical fields (campos lógicos): http://zaguan.unizar.es/admin/bibindex/bibindexadmin.py/field
Indexes: permite
definir índices que
después se utilizarán
para la búsqueda. Un
index puede contener
uno o más logical fields.
P ej: el index collection
se puede usar para
hacer búsquedas tipo:
collection:FH

Logical fields: son parte
de un index. En cada
logical field se definen
las etiquetas MARC
que se usarán para
dicho logical field.
Por ejemplo, para
collection se usa la
980__% (a,b,c,…)

BIBFORMAT: gestión de formatos http://zaguan.unizar.es/help/admin/bibformat-admin-guide

Output formats: definen los distintos formatos de salida para los registros del Repositorio 
/record/XXX?of=CODIGO&verbose=9


Output formats: definen los distintos formatos de salida para los registros del Repositorio 
/record/XXX?of=CODIGO&verbose=9

BORRADO DE CACHÉ:
echo "DELETE FROM bibfmt WHERE format='hb'" | /soft/cds-invenio/bin/dbexec
echo "DELETE FROM bibfmt WHERE format='HB'" | /soft/cds-invenio/bin/dbexec

ACTUALIZACIÓN DE CACHÉ:
Now suppose you don‟t want to delete the information, but only to update the cache information. Then you should type:
sudo -u apache /soft/cds-invenio/bin/bibreformat –a
If you only want to update a collection‟s output format you should type:
sudo -u apache /soft/cds-invenio/bin/bibreformat -c “Fondo Histórico”.
Note that the -c parameter value must be the name of desired collection which can be seen in websearch admin screen:
$YOUR_SITE_NAME/admin/websearch/websearchadmin.py?colID=1&mtype=perform_showall


Output formats: definen también REGLAS tipo firewall sobre qué plantilla aplicar …
Por ejemplo, para el
formato HTML
BREVE (HB) se
definen las siguientes
reglas.

Si la etiqueta 980.a
del registro es igual a
„PICTURE‟, entonces
usa el TEMPLATE
„Picture HTML brief‟.

¿Qué es un
TEMPLATE? Es una
PLANTILLA de
FORMATO.


Output templates:
Cada PLANTILLA
DE FORMATO
está compuesta
por un conjunto
de <tokens>.

Cada <token>
muestra el valor
de una de las
etiquetas.


Output templates: cada token se “traduce” en un fichero .py (Python) del sistema.

[root@zaguan cdsadmin]# find /soft -name "*bfe_authors*"
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art.pyc
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_book.py
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art.py
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_book.pyc
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_tesis.py
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors.pyc
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art2.py
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_tesis.pyc
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors.py
/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art2.pyc

WEBCOLL (WEBSEARCH): gestión de colecciones
http://zaguan.unizar.es/help/admin/websearch-admin-guide?ln=es

Una
colección
puede ser
REGULAR
o VIRTUAL.
Las
colecciones
con relación
REGULAR
aparecen
en la parte
izquierda
del
Repositorio.
Las
colecciones
con relación
VIRTUAL
aparecen
en la parte
derecha.

WEBCOLL: gestión de colecciones http://zaguan.unizar.es/help/admin/websearch-admin-guide?ln=es

Una colección se define como una QUERY (consulta/búsqueda). Usualmente se
hace contra el índice collection (referencia a la 980__%).

Por ejemplo, todos los registros que tengan 980__%=TAZ (equivale a
collection:TAZ).

A la colección se le da un ID y un nombre (translation). Es conveniente que sean
iguales.

WEBCOLL: portalboxes http://zaguan.unizar.es/help/admin/websearch-admin-guide?ln=es

Forzar actualización de portalboxes o la
actualización de webcoll en general:

webcoll --force

Flujo de trabajo en el modelo de Open Access.

ARCHIVAR: ¿cómo se almacena la información?

VALIDACIÓN
MANUAL (modo colaborativo)
(Personal BUZ)

AUTOMÁTICO (Harvesting)
Importación desde otros
Catálogos/repositorios

GUIA PARA EL ADMINISTRADOR:
http://zaguan.unizar.es/help/admin/webaccess-
WEBACCESS: gestión de roles, autorizaciones, admin-guide

etc GUIA PARA EL PROGRAMADOR:
http://invenio-
demo.cern.ch/help/hacking/webaccess-
internals
ROL = conjunto de
usuarios (admite
expresiones regulares).
Definición tipo firewall:
allow email
“miguelm@unizar.es”

deny any

ACCIÓN = conjunto de
operaciones que se
pueden realizar en el
Repositorio
(submit), (referee),
(runcfgxxx) ,…
AUTORIZACIÓN = regla que relaciona
ROLES con ACCIONES

WEBACCESS: comportamiento POR DEFECTO. admin-guide

GUIA PARA EL PROGRAMADOR:
http://invenio-
¡EL COMPORTAMIENTO POR DEFECTO NO demo.cern.ch/help/hacking/webaccess-
internals
ES EL QUE SE DICE EN LA AYUDA!

The default behaviour (at least in recent versions) is to
authorize users to submit if there is no
authorization specifically defined (i.e. a role
connected to an action).

The action becomes restricted for "everybody" as
soon as you add an authorization for the given
submission and action.

So if you don't add an authorization for doctype=TAZ,
act=SRV (even with an empty role), anybody can use
this action. To review who used this submission (and
check if they were authorized) your can run:

$ echo "SELECT * from sbmSUBMISSIONS where doctype='TAZ' and
action='SRV'" | /opt/cds-invenio/bin/dbexec


http://invenio-
internals


http://invenio-
internals

cfgXXX = configurar XXX
módulo. [AVANZADO]

runYYY = ejecutar
determinada tarea de
bibsched. Salvo
runbibedit, el resto NO
tocar.

Submit: enviar
documentos (SBI, MBI,
APP, SRV)

Referee: a quién se avisa
para moderar.

Submit APP vs Referee:
el primero define quién
puede, y el segundo a

ARCHIVAR – Ejemplo: Harvesting de CERN

bibharvest -vListRecords
-f2009-12-01
-pmarcxml
-o/home/cdsadmin/harvestCERN20091201.txt
http://cdsweb.cern.ch/oai2d

http://www.openarchives.org/pmh/tools/tools.php

DIFUNDIR: Acceso a servidor web (http://zaguan.unizar.es)

- Herramientas usuales de búsqueda
- Búsquedas por colección o por otros criterios personalizables
- Establecimiento de grupos (comunidades)
- Herramientas de seguimiento (cestas)

DIFUNDIR: Acceso OAI (http://zaguan.unizar.es/oai2d)

OAI = Open Access Initiative
(iniciativa de acceso abierto)
http://www.openarchives.org

- Protocolo para máquinas
- Maximizar y simplificar difusión
- Evitar replicación de contenidos

Ejemplos query OAI:
Identificar repositorio:
http://zaguan.unizar.es/oai2d?verb=Identify

Listar sets
http://zaguan.unizar.es/oai2d?verb=ListSets

Obtener formatos de metadatos
http://zaguan.unizar.es/oai2d?verb=GetRecord&metadataPref
ix=oai_dc&identifier=oai:zaguan.unizar.es:100

Obtener un registro en un formato Más ejemplos de query’s soportadas:
http://www.leccionespracticas.com/cds-invenio/oai-pmh-verb-
determinado parameters/
http://zaguan.unizar.es/oai2d?verb=GetRecord&metadataPref
ix=oai_dc&identifier=oai:zaguan.unizar.es:100

OAI server: cómo configurar un SET http://zaguan.unizar.es/help/admin/bibharvest-admin-guide#3
http://www.leccionespracticas.com/cds-invenio/cds-invenio-
understanding-oai-setspecs-collections-and-phrases

The first two fields (setSpec and
setName) are the ways to identify
your new set. First one is the
machine-readable name and the
second, the human-readable one.
Usually I type the same name in
both fields.
In my example I will type „public‟
in these fields.

The next field is Collection(s).
Here you must type the
Collection(s) to which belong the
records you want to add to the
OAI. For instance, I have a
collection called “Tesis” so I type
“Tesis” in this field. Please note
this name is exactly the one
displayed in WebSearch admin
interface when listing the
collections. This is NOT the
value you use to define a
collection (see images below).
From now on I‟ll call the first
Collection Names and the second
Collection Queries.

OAI server: cómo configurar un SET http://zaguan.unizar.es/help/admin/bibharvest-admin-guide#3

Next fields are Phrases. I was
wondering how this Phrases
and collections were evaluated.
This is the way it works:

1) the union of the Collection(s)
you specified is taken (let‟s call it
A).

2) on this you apply the (at most)
TIPS: three condition reading them from
1) If you want to add a phrase which involves a concrete field left to right. So e.g. if you have “X
(ie:984) you should make sure it is already defined. To do this and Y or Z” phrase‟s, all the
refer to: records from A that match X are
http://yourURLToCDSINVENIO/admin/bibindex/bibindexadmin.p intersected with all the records
y/field. If it is not defined there, add the definition. from A that match Y. Then this is
united with all the records from A
2) If you want to add a phrase which involves collections you that match Z.
should use the „Collection Query‟. This is, in this case I would
use “THE” instead of “Tesis”, as “Tesis” collection is defined like
collection:THE (refer to previous section for further explanation).

OAI server: ejemplo de definición de SET complejo
http://zaguan.unizar.es/help/admin/bibharvest-admin-guide#3

Let‟s suppose you want to define a OAI set, called „public‟, which involves Collection (names) A,B,C and
only some of the records in collection (name) D, this is an OAI set is defined as a union of definitions.
The records belonging to collection D must be included only if the 984a field contains exactly the word
“public”.
What you can actually do is:
(i) define a first “public” setSpec with:
Collection(s): A,B,C
(ii) define a second “public” setSpec with:
Collection(s): D
Phrase: public 984__% Exact phrase

PRESERVAR: ¿cómo se almacena la información para asegurar que SIEMPRE
estará disponible?

Buenas prácticas y El COSTE de la
requerimientos preservación
USO de formatos Preservar es caro (recursos
estándar ( texto, video, humanos, recursos
sonido, imágenes) informáticos…)

Descripción bibliográfica: ¿Hay que preservarlo todo?
DC, MARCXML, METS ¿qué debemos preservar?

Adaptación a los cambios PREMIS
tecnológicos http://www.loc.gov/standards/premis/

CDS INVENIO
DÍA 2: DEFINIENDO UN NUEVO DOCTYPE
CON WEBSUBMIT


PASO 0: Consideraciones previas

Almacenar sí vs Almacenar no:
- ¿Es interesante almacenar este nuevo “tipo de documento”?
- ¿Qué volumen de envíos de este tipo podría producirse si se implementa?
- ¿Qué volumen de consultas?

Preservar sí vs Preservar no:
- ¿Interesa preservarlo?
- ¿Cuál va a ser el coste de preservarlo?
- ¿Cuál va a ser la FORMA de preservarlo?
- ¿Cuánto tiempo?

PERMISOS / DERECHOS de autor:
- ¿quién va a poder enviar?
- ¿va a ser un envío moderado?
- De ser moderado, ¿Quién lo va a validar?
- ¿Quién lo va a poder CONSULTAR?
- ¿A texto completo o solo los metadatos?

PASO 1: Buscando el MARC más completo posible
PASOS:

• ¿Es un nuevo “tipo” de documento o “encaja” en alguna subcategoría de los
existentes? Aunque no “encaje” en subcategorías, ¿cómo se guardan los datos
SIMILARES? (P ej, si va a tener keywords y hay otros doctypes con keywords,
¿cómo se guardan? ¿dónde se guardan?)

• ¿Cómo se procede en otros repositorios para almacenar este tipo de
contenido? ¿Qué tipo de FORMATO es el más conveniente para almacenar este
tipo de documento? ¿Va a ser el hosting LOCAL o REMOTO (=cargar fichero o
añadir URL)?

• ¿Qué información (metadatos) es ESENCIAL que contengan los registros de
este “tipo”?

• ¿Qué información (metadatos) podría contener este “tipo” de documento, pero
no es imprescindible?

PASO 1: Buscando el MARC más completo posible

PASOS:

-Definir un “modelo” en MARC teniendo en cuenta el registro con más metadatos
que exista. Por ejemplo:
<record>
<controlfield tag="001">4574</controlfield> ESTOS DATOS LOS GENERARÁ EL
<datafield tag="037" ind1=" " ind2=" "> SISTEMA. NO hay que pensar cómo
<subfield code="a">TESIS-2010-039</subfield> generarlos
</datafield>
<datafield tag="041" ind1=" " ind2=" ">
<subfield code="a">spa</subfield>
</datafield>
<datafield tag="100" ind1="1" ind2=" ">
<subfield code="a">Sáenz Preciado, Jesús Carlos</subfield>
</datafield>
<datafield tag="245" ind1="0" ind2="0">
<subfield code="a">La Terra Sigillata Hispanica del Municipium Augusta Bilbilis</subfield>
</datafield>
<subfield code="b">Universidad de Zaragoza</subfield>
<subfield code="a">Zaragoza</subfield>
<subfield code="c">1997</subfield>
</datafield>
<subfield code="a">990</subfield>
</datafield>

…

</record>

PANTALLA CONFIG. doctype (WEBSUBMIT)

PANTALLA CONFIG. doctype (WEBSUBMIT)
Acciones: definen el tipo de View INTERFACE (formulario
formulario que se creará: HTML)
APP = APProval View FUNCTIONS
SBI = SuBmIt (operaciones a ejecutar y orden
MBI= Modify
de las mismas)
SRV = Submit files

Se empieza definiendo la
INTERFAZ de envío de nuevos
documentos (para la acción
SBI).

Familiarizarse con los
ELEMENTS existentes en el
sistema.

PASO 2: DEFINIR FORMULARIOS DE ENVÍO
PASOS:

- Ya tenemos los DATOS que hay que solicitar al usuario = sabemos qué campos
son necesarios. También sabemos si son opcionales u obligatorios. Hay que
pensar en QUÉ hay que validar sobre esos datos (p. ej: si es fecha, que sea
formato DD/MM/AAAA y que fecha insertada sea anterior a la actual).

- Nos fijamos cómo están definidos los formularios de OTROS doctype ¡¡SIN
MODIFICARLOS!!

.

Un formulario = conjunto de ELEMENTS, LABEL‟s, LEVEL‟s y CHECK‟s.

ELEMENT = aglutina el TIPO DE <INPUT> y el MARCCODE asociado.

LABEL = modificador HTML que se coloca PRECEDIENDO a cada ELEMENT.

LEVEL = O:optional, M:mandatory

CHECK = Función JS a aplicar al <input> (por ejemplo, DateCheck)

Veamos el ELEMENT llamado „DEMOBOO_TITLE‟

PASO 3: DEFINIR LAS FUNCIONES QUE SE EJECUTAN TRAS EL ENVIO
[AVANZADO]
Dos casos básicos: (1) Envío MODERADO (2) Envío SIN MODERAR.
EJEMPLO: (1)

[AVANZADO]
Para cada Function ajustamos los PARAMETERS.

Eliminar la función
“move to done” es
muy útil para hacer
un DEBUG cuando
se produce algún
tipo de problema
con los envíos.

.

[AVANZADO]son los más IMPORTANTES. Indican cómo debe crearse el registro (la equivalencia
Estos ficheros
entre ELEMENTS y el MARCXML del registro que se creará)

.

[root@zaguan cdsadmin]# find /soft -name DEMOTHE.tpl
/soft/cds-invenio/etc/bibconvert/config/DEMOTHE.tpl

PASO 4: Crear la COLECCIÓN REGULAR para el nuevo doctype
Ya tenemos todos los pasos hechos para poder realizar envíos de nuevos registros.

El valor que hemos puesto (de forma estática) para la colección (en el
MARCTAG 980__a) define la query que deberemos asignar a la
colección.

Lo único que falta es crear (si procede) la nueva colección que agrupe estos registros nuevos.

Para definir una nueva
colección se usa el
módulo WebSearch.

“Create new collection” y
nos pide el “Default
name”

Vamos a ver los pasos y valores necesarios para definir la nueva colección…

Para definir una nueva
colección se usa el
módulo WebSearch.

“Create new collection” y
nos pide el “Default
name”

Después se selecciona la
“Parent collection” y la
“Relationship”.

La colección ya está definida. Ahora hay que editarla y añadirle la QUERY necesaria para que
funcione… La misma cadena que hemos usado en el DEMOTHEcreate.tpl la
ponemos como query en el campo de “Modify collection query for collection
‘ejemplo‟”

La colección (y su query asociada) están completamente definidas, ¿cómo sigo?

La nueva colección aparece pulsando “Show all”,
pero NO aparece aun en la página principal.

¿Cómo hacer que aparezca? Hay que esperar a la
ejecución de webcoll en bibsched (si está en modo
automático) o ejecutar manualmente la tarea webcoll
en bibsched (R). Si pese a todo no se actualiza, se
puede forzar manualmente:
[root@aneto cdsadmin]# sudo -u apache webcoll --force
WebColl Task Submission
=======================
Username: miguelm@unizar.es
Password:

PASO 5: VERIFICAR QUE LOS NUEVOS REGISTROS APARECEN EN LA
NUEVA COLECC.
La colección está totalmente definida. Si enviamos un registro debería
aparecer dentro de su colección.

¿Qué hacer si no aparece?

1. Acceder al registro, a su visualización XM (marcxml) y verificar que la
980__a contiene la MISMA CADENA de texto que contiene la query de
la colección.

2. Ejecutar manualmente las tareas de bibsched (todas dos veces).

3. Actualizar la página.

PASO 6: GESTIONAR LOS PERMISOS CON WEBACCESS
Los envíos funcionan. Los registros aparecen dentro de su colección.

Falta definir PERMISOS.

- Crear ROL (si no existe ya uno apropiado para tal fin)

- Crear autorizaciones (qué acciones puede hacer cada rol)

- Verificar el funcionamiento.

Cds invenio

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Empfohlen

Empfohlen (20)

Cds invenio