My Blog on Oracle OTN LAD

Hello ALL,

I’m glad to announce that My Blog is on the Oracle OTN LAD: http://www.oracle.com/technology/global/lad-pt/blog/index.html

Thanks,

UCM Backup

Há basicamente 4 áreas no Content Server que devem ser feitas backups regulares:

• • Repositório de arquivos nativos (“Vault”)
  • Repositório dos arquivos web-viewable (“Web Layout”)
  • Content Information database (banco de dados onde ficam os metadados)
  • search index (indices de busca)

Dessas 4 áreas ,os dois repositórios de arquivos e o content information database são os mais importantes o UCM não vai poder ser recuperado com sucesso se não tivermos o backup deles. Sem os arquivos do repositório, não há conteúdo. Sem o content information database (que armazena os metadados), o Content Server não saberá nada sobre o conteúdo, o que significa que o conteúdo não existe.

• Os backups dos arquivos no repositório e do content information database devem ser sincronizados sempre que possivel. O ideal seria que o Content Server e o banco de dados sejam parados antes do backup. Isso nos permite uma sincronização máxima, visto que nenhum conteúdo pode ser armazenado enquanto o backup está sendo feito. Se isso não puder acontecer, esteja certo de que o backup está sendo feito durante periodos de baixa atividade do sistema (por exemplo, nas madrugadas ou nos finais de semana).
• É recomendado que você inclua também na sua politica de backup toda a estrutura de diretórios do Content Server. Isso assegura que voce irá fazer backup de todos os arquivos de configuração e outros arquivos importantes (por exemplo, componentes customizados, etc).

 

Com base nessas  informações segua abaixo a lista dos diretórios que devem ser feitos backups e uma sugestão da frequência com que devem ser feitos os backups.

D:\diretorio de instalação\server\weblayout (BACKUP DIÁRIO)
D:\diretorio de instalação\server\vault (BACKUP DIÁRIO)

D:\diretorio de instalação\server\config (BACKUP SEMANAL)
D:\diretorio de instalação\server\custom (BACKUP SEMANAL)
D:\diretorio de instalação\server\bin (BACKUP SEMANAL)
D:\diretorio de instalação\server\admin (BACKUP SEMANAL)

Integração – Content Server & Active Directory

O Content Server é desenhado para 2 tipos de usuário e 2 tipos de administradores:

Consumers: Usuários que necessitam somente: procurar, achar, visualizar e imprimir arquivos.

Contributors: Usuários que precisam criar e revisar arquivos.

Administrators: Administradores que supervisionam uma instância inteira.

Sub-administrators: Administradores que supervisionam um subconjunto ou parte de uma instância.

Em um cenário típico, a maioria dos usuários são Consumers. Esses usuários não necessitam de um user name e um password para acessar o Content Server a menos que alguma política de segurança seja aplicada aos arquivos. Para garantir a integridade dos arquivos, os Contributors necessitam de um user name e um password para fazer check-in de arquivos no sistema.

Normalmente a maioria dos administradores são sub-administradores. Eles administram “porções” do software que correspondem às permissões que o System Administrator atribui a eles.

O Oracle Content Server oferece 2 tipos de segurança no que diz respeito ao conteúdo: security groups (que são obrigatórios) e accounts (que são opcionais). Cada item de conteúdo é relacionado com um security group, e se você utilizar accounts, os items de conteúdo podem ser relacionados também com uma account. Aos usuários são atribuídos certos níveis de permissão (Read, Write, Delete, ou Admin) para cada security group e account, que lhes permitam trabalhar com apenas um item de conteúdo, na medida em que tenha permissões para o item de segurança do security group e/ou da account.

Nesse caso um usuário pode ser atribuido a um grupo que tem um DN (distinguished name):

cn=Project1 OU=TopSecret, OU=Accounts, OU=Stellent, dc=company, dc=com

USUÁRIOS EXTERNOS

Usuários que são autenticados através de mecanismos de segurança externa (Active Directory ou LDAP) são considerados usuários externos no Content Server. A primeira vez que o usuário logar no Content Server, ele será adicionado na tabela USERS do banco de dados, e os administradores do sistema podem ver informações sobre esse usuário através do Repository Manager. Entretanto, usuários externos não são incluidos nas user lists, como o campo Author por exemplo numa página de Check-In. Por padrão, a integração com os mecanismos de segurança externa mapeia somente alguns dados sobre o usuário (user name, password, roles, e accounts). Se você está usando integração com o  Active Directory ou LDAP, informações adicionais sobre o usuário, como endereço de e-mail ou local do usuário, podem ser mapeados para a página de administração do Content Server.

Algumas restrições de segurança do Content Server:

Web Server: IIS 5.0 ou mais recente.

Usuários: Usuários devem estar em um grupo global ou local no domínio do Windows

PROCESSO DE AUTENTICAÇÃO NO ACTIVE DIRECTORY

Quando a segurança do Active Directory é integrada com o Content Server, o IIS e o filtro do webserver trabalham da seguinte maneira para autenticar um usuário:

1. O cliente faz uma requisição para o IIS.

2. Se alguma credencial é exigida para fazer essa requisição, o filtro do web server verifica se o usuário está definido como um usuário interno no Content Server.

• Se o usuário é definido como um usuário local ou global do Content Server, as roles, accounts, e os atributos do usuário definidos no Content Server são usados.

•Se o usuário não está definido, ou é definido somente como um usuário externo no Content Server, o filtro do web server aplica a seguinte sequência:

a. O web server faz uma requisição para o Active Directory requerendo o password do usuário.

b. O filtro do web server valida o password do usuário.

c. Quando essa etapa é concluida com sucesso, o filtro do web server recupera o grupo ao qual pertence o usuário do servidor do Active Directory.

d. O grupo do Active Directory ao qual o usuário pertence é mapeado para as roles e accounts do Content Server.

e. O filtro do web server recupera informações sobre o usuário, como o e-mail e o tipo de usuário do servidor do Active Directory.

3. Se essa requisição for uma CGI URL, a requisição é repassada ao Content Server junto com as roles e accounts do usuário.

4. Se essa requisição for uma URL estática, o filtro do web server vai checar as roles e accounts do usuário para verificar se o usuário tem permissões suficientes para acessar aquela requisição.

MAPEANDO ROLES E ACCOUNTS

Quando o Active Directory está integrado com o Content Server, o grupo no Active Directory ao qual o usuário pretence, é mapeado junto com as roles e accounts:

Se um nome do grupo é analisado como uma role e corresponde ao nome de um role no Content Server, é concedido ao usuário permissões baseadas nesse papel.

Se o nome do grupo é analisado como uma account, o usuário é atribuído à essa account; você pode criar novas accounts de grupos do Active Directory dessa maneira.

Se os nomes dos grupos no AD não baterem com as roles ou accounts no Content Server, eles serão ignorados.

Permissões nas accounts são determinadas pelo nome do grupo em si ou pela permissão default.

GROUP FILTERING (ROLES E ACCOUNT PREFIXES)

Group Filtering são usados para especificar quais partes dos grupos do Active Directory vão ser mapeados para as roles e accounts do Content Server.

Quando o Group Filtering está habilitado no Active Directory Configuration Page os campos Role Prefix e Account Prefix são usados para filtrar cada nome de grupo de usuário. Você pode especificar um número ilimitado de roles prefixes e account prefixes, que na verdade são substrings que são comparadas com cada group name do Active Directory. Se um prefixo de uma substring é achado em um group name, o resto do group name depois desse prefixo (a um nivel mais baixo na árvore de diretórios) será entendido como uma role ou account.

O resultado do mapeamento da role e account depende se a setting: Full Group Names estiver habilitada. Se estiver desabilitada, todos os group names serão entendidas como Content Server roles, de acordo com as configurações do Full Group Names. Cada role prefix e account prefix tem que ter um parâmetro Depth, que especifica número máximo dos níveis que podem existir entre o prefixo e a última unidade do group name, para que o grupo seja considerado uma role ou account válida.

Coloque um asterisco (*) no parâmetro depth para que um determinado prefixo garanta um nome curto para qualquer grupo mapeado. Por exemplo, para um grupo com um DN CN=TestApp,OU=Apps,OU=Roles,[LdapSuffix]:

Role Prefix	> Role Name
OU=Roles[4]	> Apps/TestApp
OU=Roles[*4]	> TestApp

O exemplo abaixo são prefixos de roles e accounts, onde a árvore de diretórios inclui uma OU chamada Stellent, com OU’s “filhas” chamadas de Roles e Accounts:

Role Prefix: OU=Roles,OU=Stellent

Account Prefix: OU=Accounts,OU=Stellent

Nota: Não inclua espaços antes ou depois das vírgulas que separam os prefixos.

O Content Server transforma qualquer % numa barra (/) para fazer estruturas hierárquicas. Por examplo, um Group Name FOO%BOO%BASH é mapeado para a account como FOO/BOO/BASH.

EXEMPLO DE MAPEAMENTO DE ROLES

Group: CN=admin,OU=Mgr,OU=Dept,OU=Roles,OU=Stellent,dc=company,dc=com

Role Prefix: OU=Roles,OU=Stellent[2]

Group Filtering Full Group Names Result

Enabled Enabled Role = Dept/Mgr/admin

Enabled Disabled Role = admin

Disabled Enabled Role = Stellent/Roles/Dept/Mgr/admin

Disabled Disabled Role = admin

EXEMPLO DE MAPEAMENTO DE ACCOUNT

Group: CN=admin,OU=Mgr,OU=Dept,OU=Accounts,OU=Stellent,dc=company,dc=com

Role Prefix: OU=Accounts,OU=Stellent[2]

Group Filtering Full Group Names Result

Enabled Enabled Account = Dept/Mgr/admin

Enabled Disabled Account = admin

Disabled Enabled Role = Stellent/Accounts/Dept/Mgr/admin

Disabled Disabled Role = admin

PERMISSÕES EM ACCOUNTS

Permissões em accounts podem ser especificadas da seguinte maneira:

Nas account settings especifique o Default Network Accounts na página Active Directory Configuration. O default é #none(RWDA), o que significa que os usuários do Active Directory tem permissões de Administrador para todos os items de conteúdo que não são ligados à uma account.

Segue abaixo uma série de passos para integrar o UCM (UNIVERSAL CONTENT MANAGEMENT) com o  Microsoft Active Directory

1. Criar uma OU no Active Directory chamada Stellent

2. Criar uma sub-OU debaixo de Stellent chamada Roles

3. Debaixo de Roles, crie os Security Groups do AD com o mesmo nome das Roles do UCM (ex. contributor, admin)

4. Na Home Page do Content Server, abra a página Admin Server

5. Abra o Content Server instance que sera integrada ao AD

6. Abra a página Internet Configuration

7. Na opção Microsoft Security escolha a opção Active Directory Security

8. Restarte o Content Server

9. No Content Server Home Page, debaixo de Administration abra a página Filter Administration

10. No Active Directory Security, clique no link Configure

11. Abaixo de Role Prefix, adicione o seguinte “OU=Roles,OU=Stellent”

12. Clique em Update

13. Restarte o Content Server e o IIS

Convertendo Documentos com o Ghostscript 8.64 ou posterior (IBR) (DAM)

Então você tentou converter os documentos do ContentServer usando às versões mais novas do Ghostscript não é?

Ah….e adivinha….DEU ERRO!!!!

BEM aqui segue um “WORKAROUND”….mais conhecido como GAMBIARRA…para fazer o “bichinho” funcionar.

Quando o Ghostscript v8.64 ou posterior é usado, são requeridas algumas variáveis adicionais no Intradoc.cfg para que o Content Server possa se comunicar corretamente com o Ghostscript.

Neste exemplo o GhostScript 8.64 está instalado no seguinte diretório: C:\Ghostscript\gs\gpl\gs8.64

EXPORT_CUSTOM_GS_LIB=GS_LIB
CUSTOM_GS_LIB=C:/Ghostscript/gs/gpl/gs8.64/lib
EXPORT_CUSTOM_GS_DLL=GS_DLL
CUSTOM_GS_DLL=C:/Ghostscript/gs/gpl/gs8.64/bin/gsdll32.dll

A variável GS_LIB tem que ser setada no diretório /lib e a variável GS_DLL
tem que ser setada para onde está o arquivo gsdll32.dll.

A Oracle promete que futuras versões do IBR irão suportar essas versões mais novas do Ghostscript sem precisarmos fazer esse “workaround”.