Blog

UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia 3 p Tí ULO DO TRABALH Consulting for Software Developer cumprimento da legislação vigente, por parte de alguns gestores, o que poderia prejudicar gravemente tanto a imagem quanto a credibilidade da empresa Software Developer. PALAVRAS-CHAVE: Consultoria, gestão, hardware.

Abstract It was made a consultant to identify issues that were hampering the operation of a software com an . n developing the consulta d several flaws that 23 assessoria o primeiro passo é entrevistar a pessoa responsável ara adquirir informações referentes à empresa para poder saber como ela funciona e ver quais são suas deficiências e estabelecer um ponto de partida para solucionar os problemas existentes.

Nessa entrevista primeira coisa a ser descoberta foi que estava começando a faltar espaço no hardware do banco de dados e que tinham sido investidos capital em smartphones e laptops, sendo assim a acessória deveria dar uma solução para que esse investimento não seja comprometido caso houvesse uma perda de espaço no hardware e não fizesse uma nova modelagem para o banco de dados. Conversando mais um tempo com o responsável pela empresa a acessória descobriu vários pontos fracos na gestão de funcionários que era preocupante.

Depois de todos os pontos relatados a assessoria passou para o cliente o que poderia ser feito para ajudar a empresa superar as dificuldades encontradas. necessario. Depois desse procedimento clico em ok e o problema de espaço de hardware esta resolvido. MODELAGEM DE DADOS O Samba é um conjunto vasto de programas “open-source”, especialmente desenvolvidos para Linux (embora seja suportado por muitas implementações Unix e nao só) cujo grande objetivo é Integração do sistema Unix no ambiente de rede da Microsoft.

Embora os mais notórios sejam os componentes que implementam as funções de servidor, sendo considerado “o servidor Windows mais rápido existente”, o “software” Samba no seu conjunto permite um elevado grau de integração dos sistemas Unix no ambiente de rede Microsoft, em diversos aspectos e sob diversos tipos de configuração. Sob uma perspectiva de substituição dos sistemas servidores da Microsoft é fundamental compreender que o Samba não é suportado de forma alguma pela Microsoft (antes pelo contrário).

Uma vez que os sistemas Windows são proprietários, para cada evolução nos sistemas Microsoft, existe um lapso de tempo razoável até que as mesmas funcionalidades sejam suportadas pelo Samba. Esse lapso de tempo corresponde a um processo de investigação das novas funcionalidades e implementação das mesmas. Por exemplo, de momento (Novembro de 2003), o Samba tem como ultima versão estável “3. 0. 0”, algumas das características como servidor são: • Suporte total das funçóes “Primary Domain Controller” (PDC) tal como eram implementadas pelo ‘Windows NT Server 4. 0″.

Não suporta ainda as funções PDC em modo “Active Directory” do “Windows 2000 Server”. • Pode contudo integrar-se num dominio “Active Directory”. • Suporta o MS-DFS (sistema de ficheiros distribuido da MicroSoft 4 23 Directory”. • Suporta o MS-DFS (sistema de ficheiros distribuído da MicroSoft). • Suporta o sistemas avançados de impressão, incluido a instalação automática de “drivers”. Muitas vezes a simples instalação de um novo “Service pack’ nos clientes pode provocar problemas, novamente é necessário esperar algum tempo até que a equipa que desenvolve o Samba resolva essa situação.

Servidor Samba O servidor Windows é constituído por duas aplicações separadas: • nmbd – esta aplicação implementa as funções NetBIOS de resolução de nomes, registo de nomes e recolha de listas de “browse”. pode funcionar como servidor WINS ou usar servidores WINS existentes. • smbd – é o servidor propriamente dito, desde logo implementa o protocolo SMB para acesso aos ficheiros, mas vai muito além disso, acompanhando as funcionalidades crescentes dos servidores Microsoft, assim atualmente implementa ainda os protocolos AOS, RAP e RPC.

Sob o ponto de vista das funções de controlador de dominio o ervidor é equivalente a um controlador de domínio NT Server, com todas as funcionalidades associadas tais como: • Autenticação com “password” protegida (cifrada). • Identificação por SID. • “Login” no domínio com fornecimento de credenciais que permitem o acesso a todas as máquinas do domínio. As máquinas do domínio podem incluir qualquer tipo de sistema da Microsoft (NT, 2000, XP, nas versões “Server’ ou “Workstation Login Script” • “Home Directory” e “Roaming Profile” • “Politicas de Sistema”.

ACLs As ACLs que se espera de um servidor Windows são substancialmente diferent o (“Posix ACLS”), o OF23 servidor Windows são substancialmente diferentes das ACLs do Unix (“Posix ACLs”), o servidor Samba tenta criar uma equivalência o mais coerente possível, assim: • O UID e GID dos ficheiros Unix é transformado em SIDs. • Apenas são possiVeis as permissões RWX, na ausência de permissões, é ativada a permissão Windows “O” (por semelhança com 0 0). • As permissões Unix correspondentes ao UID são apresentadas sob a forma de uma entrada na ACL. om o SID equivalente. • As permissões Unix correspondentes ao GID são também transformadas numa entrada na ACL, agora com o SID correspondente ao CID. ?? As permissões Unix correspondentes a “others’ são materializadas na ACL sob a forma de uma entrada associada ao grupo “EVERYONE”. Os atributos Windows “Archive”, “System” e “Hidden” também não têm qualquer equivalente em Unix, o servidor Samba permite no entanto que estes atributos sejam associados aos bits “execute” do Unix, respectivamente para o “owner”, “grupo” e ” others”.

Bases de dados do Servidor Samba O servidor Samba tem necessidade de manter um vasto conjunto de informação necessário às funções de servidor Windows, de entre esta informação assume particular destaque as contas dos tilizadores. Entre outras informações as contas de utilizador Windows devem conter: • O nome do utilizador. • O SID do utilizador. • O SID do grupo primário do utilizador. • A “password” do utilizador (armazenada em dois formatos de cifragem distintos adequados a dois tipos diferentes de postos de trabalho). • A localização da “home directory”. ofile” (“profile path”). • A localização do “roamin • A letra de driv 6 directory”. • A localização do “roaming proflle” (“profile path”). • A letra de drive a mapear para a “home directory”. • O “login script” do utilizador. ?? O nome completo do utilizador. • A descrição da conta. • Os postos de trabalho que o utilizador pode usar. • Tipo de conta (Utilizador, Máquina, Disabled, • Politicas de conta (mudança de password, etc). O conjunto de informação relativo às contas de utilizador em Windows é normalmente conhecido por SAM (“Security Account Manager”).

O tipo de base de dados que o Samba usa para guardar este tipo de informação pode ser de diversos tipos (tipo de “backend”). Até à versão 3, o servidor samba usava para este efeito o ficheiro “smbpasswd” que era claramente omisso em muitos aspectos. Para cada utilizador, este ficheiro contém apenas o nome, o UID unix, o tipo de conta e as “passwords” cifradas, os restantes parâmetros tinham de ser iguais para todos os utilizadores, podendo incluir elementos que eram automaticamente substituidos pelo nome do utilizado.

O SID era calculado em função do CJID com recurso a uma regra aritmética simples (SID utilizador=SlD-domínio-RlD, onde RID=1000+2xUlD). Com a versão 3. 0. 0 passaram a ser suportadas diversas formas de armazenamento para além do “smbpasswd”, de entre elas MySQL e LDAP. Estas novas formas de armazenamento não ossuem as limitações do “smbpasswd” e suportam todos os campos necessários a uma conta de utilizador de um dom[nio Windows. De entre as várias opções disponíveis atualmente, uma das mais atrativas sob o ponto de vista de integração é o LDAP.

Utilizadores Unix e utilizadores Windows Embora o Samba de de integração é o LDAP. Embora o Samba defina contas de utilizador apropriadas para o ambiente de domínio Microsoft, internamente tem de funcionar com contas Unix, porque apenas estas são reconhecidas pelo Sistema Operativo. Para cada conta de utilizador Windows, definida no Samba, tem e existir uma conta Unix equivalente, ou seja nao se pode criar um utilizador Windows no Samba, sem antes ter criado o utilizador Unix correspondente.

Sob o ponto de vista do administrador isto não é muito favorável porque terá de gerir em paralelo duas bases de dados de utilizadores (Unix e Windows/ Samba). As versões atuais do servidor Samba permitem a definição de um programa externo que será executado quando vai ser criado um novo utilizador Windows, a missão desse programa externo é a de criar automaticamente o utilizador Unix correspondente. Se pretendemos um maior grau de integração Unix/Windows, o

CDAP leva vantagem porque devido ao fato de o Unix suportar utilizadores em CDAP (nss_ldap e pam_ldap), e graças ao modo como o CDAP funciona, é possível ter os utilizadores em registros unicos, contendo os campos necessários tanto para o Samba como para o Unix. Grupos Unix e grupos Windows O Samba permite estabelecer relações de equivalência entre grupos de utilizadores Windows e grupos de utilizadores Unix. A necessidade de equivalência deve-se ao fato de (tal como para os utilizadores) o servidor Samba funcionar sobre Unix e como tal, no acesso ao sistema operativo, tem de usar UlDs e GIDs Unix.

Esta relação de equivalência é definida pelos administradores, ficando associado ao grupo Windows, com respectivo SID um grupo definida pelos administradores, ficando associado ao grupo Windows, com respectivo SID um grupo Unix válido. Este procedimento tem também a vantagem de contornar as limitações dos nomes de grupos Unix, que por exemplo não podem conter espaços, existentes na maioria dos grupos Windows fundamentais como “Domain Admins”, “Domain Users” e “Domain Guests”. uporte de BDC (“Backup Domain controller”) Os domínios da Microsoft sustentam-se numa máquina om funções especiais conhecido por “Primar,’ Domain Controller” (PDC). Esta máquina tem obrigatoriamente de ser única e mantém uma base de dados contendo todas as definições relativas ao domínio, tais como contas de utilizador, definições de grupos de utilizadores, contas de máquinas que pertencem ao domínio, etc, ou seja a base de dados SAM. A função PDC é identificada através do nome NetBlOS correspondente ao domínio, com o tipo de nome “1 b”.

Sempre que é necessário alterar algo num domínio (por exemplo a “password” de um utilizador), este servidor tem de estar disponível. Além do tipo de nome “Ib”, um PDC define também o nome de domínio, do tipo “1 c”, o tipo “Ic” significa “Login Server”, ou seja trata-se de um servidor que é possível usar para efetuar o “login” no domínio. Os postos de trabalho procuram o nome de domínio do tipo “1 c” para saberem onde é que os utilizadores devem efetuar o “login” no domínio.

As alterações à base de dados SAM apenas podem ser feitas no PDC, contudo nada impede que existam cópias redundantes e apenas de leitura, disponíveis em outros servidores, esses servidores podem então assumir a função “Backup Domain Controller”. Um BDC não define o tipo de nome “Ib”, isso é reservado a assumir a função “Backup Domain Controller”. Um BDC não define o tipo de nome “Ib”, isso é reservado ao PDC que tem de ser único, mas define o nome de domínio do tipo “1 c”, ou seja é um “Login Server’.

A vantagem de se dispor de um ou mais BDCs é que em caso de indisponibilidade temporária do PDC continua a ser possível efetuar o “login” no domínio, e a base de dados SAM continua disponível (nos BDC). Contudo todas as operações que envolvem alterações à base de dados são impossíveis até que o PDC esteja isponível. A existência de vários “Login Server” tem ainda a vantagem de distribuir essa tarefa por vários servidores.

Atualmente os servidores Samba nao suportam ainda os protocolos de sincronização PDC/BDC usados pela Microsoft, isto significa que o Samba pode ser BDC apenas de domínios cujo PDC é também um servidor Samba. Para isso é necessário assegurar a sincronização manual por meios externos, além da base de dados, o administrador não se pode esquecer ainda do “share” NETLOGON que deve ser igual no PDC e nos vários BDC (o NETLOGON contém elementos fundamentais tais como o login script” e as politicas de sistema).

Uma das formas mais diretas de assegurar a sincronização dos BDC com o PDC é usar um sistema de servidores LDAP, por exemplo o OpenLDAP (http://www. openldap. org) dispõe de mecanismos de replicação que permitem manter um conjunto de servidores LDAP sincronizados entre sí. Servidores Samba integrados em domínios Microsoft A grande vantagem dos servidores Samba é a sua eficiência e estabilidade, a grande desvantagem reside no fato de nunca implementar as últimas funcionalidades desenvolvidas pela Microsoft. por estas razões pode s 0 DF 23