Neste capítulo são descritas tarefas de administração avançada.
Neste exemplo pretende-se criar usuários em grupos por ano, com diretórios home comuns para cada grupo (home0/2024, home0/2026, etc). Pretende-se criar os usuários através da importação de CSV.
(como root no servidor principal)
Criar os diretórios de grupo por ano que forem necessários
mkdir /skole/tjener/home0/2024
(como primeiro usuário no GOsa)
Departamento
Menu principal: ir para 'Estrutura de diretórios', clicar no departamento 'Alunos'. O campo 'Base' deve mostrar '/Alunos'. No campo 'Ações' da caixa suspensa, escolher 'Criar' / 'Departamento'. Preencher os valores dos campos Nome (2024) e Descrição (alunos formados em 2024), deixar o campo Base como está (deve ser '/Alunos'). Guardar clicando em 'Ok'. Agora o novo departamento (2024) deve aparecer abaixo de /Alunos. Clicar para abrir.
Grupo
Escolher 'Grupos' no menu principal; 'Ações'/Criar/Grupo. Introduzir o nome do grupo (deixar 'Base' como está, deve ser /Alunos/2024) e pressionar 'Ok' para salvar.
Modelo
Escolher 'usuários' no menu principal. No campo Base, mudar para
'Alunos'. Deve aparecer uma entrada Novo
Aluno
; clique para abrir. Este é o modelo 'alunos', não é
um usuário. Uma vez que terá de ser criado um modelo com base neste (para
poder ser feita a importação csv), deve ser tomada nota de todas as entradas
que aparecem nos separadores Genéricos e POSIX, talvez fazendo capturas de
tela, para que as informações necessárias ao novo modelo possam ser
preparadas.
Agora, mudar para /Students/2024 no campo Base; escolher Criar/Modelo e começar a preencher com os valores desejados, primeiro na aba Genérico (adicionar também o novo grupo 2024 em Grupos, também); depois adicionar a conta POSIX.
Importar usuários
Escolher o novo modelo ao fazer a importação de CSV; é recomendável testá-lo com alguns usuários.
Com este script, o administrador pode criar uma pasta no diretório pessoal de cada usuário e definir permissões de acesso e propriedade.
No exemplo abaixo com grupo=professores e permissões=2770 um usuário pode entregar um trabalho guardando o arquivo na pasta "trabalhos", à qual os professores têm acesso de escrita para poderem fazer comentários.
#!/bin/bash home_path="/skole/tjener/home0" shared_folder="assignments" permissions="2770" created_dir=0 for home in $(ls $home_path); do if [ ! -d "$home_path/$home/$shared_folder" ]; then mkdir $home_path/$home/$shared_folder chmod $permissions $home_path/$home/$shared_folder #set the right owner and group #"username" = "group name" = "folder name" user=$home group=teachers chown $user:$group $home_path/$home/$shared_folder ((created_dir+=1)) else echo -e "the folder $home_path/$home/$shared_folder already exists.\n" fi done echo "$created_dir folders have been created"
Seguir estes passos para configurar um servidor de armazenamento dedicado, para diretórios home dos usuários e possivelmente outros dados.
Adicionar um novo sistema de tipo servidor
utilizando o GOsa² como descrito no capítulo Primeiros passos deste manual.
Este exemplo usa 'nas-server.intern' como nome do servidor. Uma vez configurado o 'nas-server.intern', verificar se os pontos de exportação NFS do novo servidor de armazenamento são exportados para as sub-redes ou máquinas a que se apliquem:
root@tjener:~# showmount -e nas-server Export list for nas-server: /storage 10.0.0.0/8 root@tjener:~#
Neste caso tudo o que estiver na rede principal tem acesso ao export /storage. (Isto pode ser restringido a grupos de rede ou a endereços IP específicos para limitar o acesso ao NFS como é feito no arquivo tjener:/etc/exports.)
Adicionar informação de montagem automática sobre o 'nas-server.intern' no LDAP, para permitir que todos os clientes montem automaticamente a nova exportação requerida.
Isto não pode ser feito através do GOsa², porque falta um módulo para montagem automática. Em vez disso, usar o ldapvi e adicionar os objetos LDAP necessários usando um editor.
ldapvi --ldap-conf -ZD '(cn=admin)' -b
ou=automount,dc=skole,dc=skolelinux,dc=no
Quando o editor aparecer, adicionar os objetos LDAP seguintes na parte inferior do documento. (A parte "/&" no último objeto LDAP é um carácter polivalente que corresponde a tudo o que o 'nas-server.intern' exporta, evitando a necessidade de listar pontos de montagem individuais no LDAP)
add cn=nas-server,ou=auto.skole,ou=automount,dc=skole,dc=skolelinux,dc=no objectClass: automount cn: nas-server automountInformation: -fstype=autofs --timeout=60 ldap:ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no add ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no objectClass: top objectClass: automountMap ou: auto.nas-server add cn=/,ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no objectClass: automount cn: / automountInformation: -fstype=nfs,tcp,rsize=32768,wsize=32768,rw,intr,hard,nodev,nosuid,noatime nas-server.intern:/&
Adicionar as entradas aplicáveis em tjener.intern:/etc/fstab, porque tjener.intern não usa a montagem automática para evitar montagens sucessivamente falhadas:
Criar os diretórios de pontos de montagem usando
mkdir
; editar '/etc/fstab' como adequado e
executar mount -a
para montar os novos
recursos.
Agora, os usuários devem poder acessar diretamente os arquivos em 'nas-server.intern', bastando abrir o diretório '/tjener/nas-server/storage/' utilizando qualquer aplicação em qualquer estação de trabalho, cliente enxuto LTSP ou servidor LTSP.
Há várias formas de restringir o acesso por ssh. Seguem-se algumas.
Se não forem usados clientes LTSP, uma solução simples é criar um novo grupo
(digamos sshusers
) e adicionar uma linha ao
arquivo /etc/ssh/sshd_config da máquina. Os membros do grupo
sshusers
, e apenas eles, poderão então
entrar na máquina via ssh a partir de qualquer lugar.
Gerenciar este caso através do GOsa é bastante simples:
Criar um grupo sshusers
no nível base (onde
já aparecem outros grupos relacionados, com a gestão do sistema, como
gosa-admins
).
Adicionar usuários ao novo grupo sshusers
.
Adicionar AllowGroups sshusers
a
/etc/ssh/sshd_config.
Executar service ssh restart
.
A configuração predefinida de cliente LTSP sem disco não faz uso de ligações ssh. Basta atualizar a imagem SquashFS no servidor LTSP respectivo, após a configuração do ssh ter sido alterada.
Os clientes dependentes X2Go utilizam ligações ssh com o servidor LTSP respectivo. Então, é necessária uma abordagem diferente, utilizando o PAM.
Ativar pam_access.so no arquivo /etc/pam.d/sshd do servidor LTSP.
Configurar o arquivo /etc/security/access.conf para permitir ligações a partir de qualquer lugar para (por exemplo) os usuários alice, jane, bob e john, e para todos os outros usuários somente a partir das sub-redes internas, adicionando estas linhas:
+ : alice jane bob john : ALL + : ALL : 10.0.0.0/8 192.168.0.0/24 192.168.1.0/24 - : ALL : ALL #
Se apenas forem utilizados servidores LTSP dedicados, a rede 10.0.0.0/8 poderá ser descartada para desativar o acesso interno via ssh. Nota: alguém que ligue a sua máquina a qualquer rede de clientes LTSP dedicada também terá acesso ao(s) servidor(es) LTSP.
Se os clientes X2Go estiverem ligados à rede principal 10.0.0.0/8, as coisas serão ainda mais complicadas e talvez apenas uma sofisticada configuração de DHCP (em LDAP), verificando o identificador do fornecedor (vendor-class-identifier) juntamente com a configuração PAM apropriada, permita desativar o acesso interno por ssh.