___ qstntxt ___ Problema: Eu tenho um serviço, %code% , que inicia automaticamente um servidor Seafile após a inicialização. No entanto, este serviço está falhando ao iniciar no meu servidor Ubuntu que possui uma partição %code% criptografada. O serviço requer acesso ao %code% , conforme mostrado em este guia . O serviço não inicia automaticamente o servidor Seafile, mesmo após a descriptografia manual da partição %code% . Quando eu inicio manualmente o serviço fazendo %code% , ele funciona, no entanto, me é pedido senha de decodificação para a partição %code% , embora a partição já esteja descriptografada e montada. Mesmo se eu inserir uma frase secreta errada, o serviço será iniciado sem problemas. Histórico: Estou executando o servidor LTS do Ubuntu 16.04.4 com uma partição %code% criptografada. A partição %code% é criptografada usando DMCrypt (cryptsetup). Eu usei este guia para criptografar minha partição %code% . Meu %code% está configurado com a diretiva %code% para minha partição %code% da seguinte maneira: %code% Meu %code% está configurado da seguinte forma: %code% A descriptografia da partição %code% é feita manualmente. Após cada inicialização, descriptografo remotamente a partição %code% usando o SSH com o comando %code% . Após a descriptografia, o Ubuntu monta automaticamente a partição %code% . Tentativa de solução Como o serviço Seafile ( %code% ) requer acesso à partição %code% , usei as seguintes diretrizes para a configuração do meu serviço: %code% , %code% e %code% . Abaixo está minha definição de serviço exata. %pre% Problema: Após o servidor Ubuntu ser reinicializado, faço o login remotamente usando o SSH e descriptografo manualmente a partição %code% . Confirmei que a partição %code% é montada automaticamente, no entanto, o %code% ainda falha ao iniciar devido a dependências. Quando eu manualmente tento iniciar o seafile.service usando o comando %code% , eu recebo uma senha para descriptografar a partição %code% , mesmo que ela já esteja descriptografada. Quando perguntado sobre a frase secreta, deixo em branco e pressiono enter, e não recebo outro aviso. Quando eu verifico o status do %code% , agora ele está iniciado e ativo. Eu acho que o possível culpado de %code% não ser capaz de iniciar pode estar relacionado ao sistema pedindo uma senha para descriptografar a partição %code% mesmo que ela já esteja descriptografada. Por que o sistema está solicitando a senha ao iniciar %code% manualmente quando a partição %code% já está descriptografada? Veja os passos abaixo: %pre% ___ tag123dmcrypt ___ nos ajude a editar este wiki ___

Question

Problema: Eu tenho um serviço, seafile.service , que inicia automaticamente um servidor Seafile após a inicialização. No entanto, este serviço está falhando ao iniciar no meu servidor Ubuntu que possui uma partição /home criptografada. O serviço requer acesso ao /home/sfadmin/seafile/seafile-server-latest/seafile.sh , conforme mostrado em este guia .

O serviço não inicia automaticamente o servidor Seafile, mesmo após a descriptografia manual da partição /home . Quando eu inicio manualmente o serviço fazendo sudo systemctl start seafile.service , ele funciona, no entanto, me é pedido senha de decodificação para a partição /home , embora a partição já esteja descriptografada e montada. Mesmo se eu inserir uma frase secreta errada, o serviço será iniciado sem problemas.

Histórico:

1. Estou executando o servidor LTS do Ubuntu 16.04.4 com uma partição /home criptografada. A partição /home é criptografada usando DMCrypt (cryptsetup). Eu usei este guia para criptografar minha partição /home .
2. Meu /etc/fstab está configurado com a diretiva nofail para minha partição /home da seguinte maneira: /dev/mapper/data-home /home ext4 defaults,nofail 0 2
3. Meu /etc/crypttab está configurado da seguinte forma: data UUID=myuuidhere none luks,discard,noearly,nofail
4. A descriptografia da partição /home é feita manualmente. Após cada inicialização, descriptografo remotamente a partição /home usando o SSH com o comando sudo cryptsetup luksOpen /dev/sda3 data .
5. Após a descriptografia, o Ubuntu monta automaticamente a partição /home .

Tentativa de solução

Como o serviço Seafile ( /etc/systemd/system/seafile.service ) requer acesso à partição /home , usei as seguintes diretrizes para a configuração do meu serviço: ConditionPathExists , Requires e After . Abaixo está minha definição de serviço exata.

[Unit]
Description=Seafile
ConditionPathExists=/home/sfadmin
Requires=home.mount
# add mysql.service or postgresql.service depending on your database to the line below
After=network.target mysql.service home.mount

[Service]
Type=forking
ExecStart=/home/sfadmin/seafile/seafile-server-latest/seafile.sh start
ExecStop=/home/sfadmin/seafile/seafile-server-latest/seafile.sh stop
User=sfadmin
Group=sfadmin

[Install]
WantedBy=multi-user.target

Problema:

Após o servidor Ubuntu ser reinicializado, faço o login remotamente usando o SSH e descriptografo manualmente a partição /home . Confirmei que a partição /home é montada automaticamente, no entanto, o seafile.service ainda falha ao iniciar devido a dependências.

Quando eu manualmente tento iniciar o seafile.service usando o comando sudo systemctl start seafile.service , eu recebo uma senha para descriptografar a partição /home , mesmo que ela já esteja descriptografada. Quando perguntado sobre a frase secreta, deixo em branco e pressiono enter, e não recebo outro aviso. Quando eu verifico o status do seafile.service , agora ele está iniciado e ativo.

Eu acho que o possível culpado de seafile.service não ser capaz de iniciar pode estar relacionado ao sistema pedindo uma senha para descriptografar a partição /home mesmo que ela já esteja descriptografada.

Por que o sistema está solicitando a senha ao iniciar seafile.service manualmente quando a partição /home já está descriptografada?

Veja os passos abaixo:

$ sudo cryptsetup luksOpen /dev/sda3 data
Enter passphrase for /dev/sda3:
$ sudo systemctl status seafile.service
● seafile.service - Seafile
   Loaded: loaded (/etc/systemd/system/seafile.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Mar 10 04:14:02 VM-SERVER systemd[1]: Dependency failed for Seafile.
Mar 10 04:14:02 VM-SERVER systemd[1]: seafile.service: Job seafile.service/start failed with result 'dependency'.
$ sudo systemctl start seafile.service
Please enter passphrase for disk data!
$ sudo systemctl status seafile.service
● seafile.service - Seafile
   Loaded: loaded (/etc/systemd/system/seafile.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-03-10 04:36:46 EST; 11s ago
  Process: 1589 ExecStart=/home/sfadmin/seafile/seafile-server-latest/seafile.sh start (code=exited, status=0/SUCCESS)
    Tasks: 15
   Memory: 21.2M
      CPU: 528ms
   CGroup: /system.slice/seafile.service
           ├─1614 /home/sfadmin/seafile/seafile-server-6.2.5/seafile/bin/seafile-controller -c /home/sfadmin/seafile/ccnet -d /home/sfadmin/seafile/seafile-data -F /home/sfadmin/seafile/conf
           ├─1616 ccnet-server -F /home/sfadmin/seafile/conf -c /home/sfadmin/seafile/ccnet -f /home/sfadmin/seafile/logs/ccnet.log -d -P /home/sfadmin/seafile/pids/ccnet.pid
           └─1618 seaf-server -F /home/sfadmin/seafile/conf -c /home/sfadmin/seafile/ccnet -d /home/sfadmin/seafile/seafile-data -l /home/sfadmin/seafile/logs/seafile.log -P /home/sfadmin/seafile/pids/seaf-server.pid

Mar 10 04:36:42 VM-SERVER systemd[1]: Starting Seafile...
Mar 10 04:36:43 VM-SERVER seafile.sh[1589]: [03/10/18 04:36:43] ../common/session.c(132): using config file /home/sfadmin/seafile/conf/ccnet.conf
Mar 10 04:36:43 VM-SERVER seafile.sh[1589]: Starting seafile server, please wait ...
Mar 10 04:36:46 VM-SERVER systemd[1]: Started Seafile.