Исполняемый файл jar загрузки Spring с запуском init.d от имени пользователя root вместо пользователя

ПОМОЩЬ!

Я использую встроенный скрипт запуска с SpringBoot 1.3.6 и Gradle. О, и задача distZip для архивирования.

В какой-то момент не так давно все это работало довольно хорошо... потом я сделал - не знаю что - испортил это.

Я установил пакет (по сути, разархивировал Zip) на свой Raspberry Pi и проверил права собственности и разрешения. Все принадлежит пользователю, от имени которого я хочу запустить приложение (пользователь "appservice", группа "pi"), и подтвердил, что права доступа к файлам -- во всяком случае, слишком разрешительные (755 для сценария myapp/bin/myapp и почти все остальное).

Я поместил символическую ссылку в /etc/init.d, указывающую на ~appservice/myapp/bin/myapp, и запустил update-rc.d myapp по умолчанию, чтобы ввести его в систему. Обратите внимание, что сама символическая ссылка принадлежит root/root, но я считаю, что так и должно быть, не так ли?

Я вижу две проблемы, которые, как мне кажется, взаимосвязаны.

Во-первых, независимо от того, как я запускаю скрипт (при загрузке с помощью init.d или вручную с помощью «sudo service myapp start»), он работает от имени пользователя root (в частности, пути, которые приложение пытается использовать для доступа к файлам, отображаются как /root/myapp/files вместо /home/appservice/myapp/files).

Во-вторых, приложение выйдет из строя... в частности, я получаю сообщение системного журнала "время начала операции myapp.service истекло. Завершение". за которым следует то, что выглядит как упорядоченное закрытие приложения. О, и связанное с этим ... если я запускаю «sudo service myapp start», команда никогда не возвращается. Что нового...

В-третьих, вывод журнала приложения идет в /var/log/syslog вместо /var/log/myapp.log, что кажется противоречащим тому, что говорится в документации Spring Boot.

Я прохожу финальное регрессионное тестирование развертывания для этого, и (знаменитые последние слова) я ничего не менял в последнее время... :) Нет, действительно, самым последним изменением, относящимся к дистрибутиву, было добавление каталога src/main/dist , и после этого он работал (запуск при загрузке от имени правильного пользователя).

Я бы опубликовал сценарий запуска, но, насколько мне известно, это сценарий по умолчанию, предоставляемый Spring Boot, когда вы используете задачу springBoot {executable = true}.

Вот мой полный файл build.gradle... Я не вижу ничего плохого, но, может быть, вы заметите.

    buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:1.3.6.RELEASE")
    }
}

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'spring-boot'
apply plugin: 'application'

apply from: 'gradle/gradle/helpers.gradle'

mainClassName = 'app.Application'

if (!hasProperty('mainClass')) {
    ext.mainClass = 'app.Application'
}

springBoot {
    executable = true
}

repositories {
    mavenCentral()
}

sourceSets {
  main {
    java      { srcDir 'src/main/java' }
    resources { srcDir '/src/main/resources' }
  }
  test {
    java      { srcDir 'src/test/java' }
    resources { srcDir 'src/test/resources' }
  }
}

project.ext {
  applicationVersion = "0.1.5-alpha"

  applicationRelease = isApplicationRelease()
  applicationDate = new Date()
  applicationRevision = getRevision()

  applicationVersionSnapshot = (!applicationRelease) ? "+SNAPSHOT.${asUTC(applicationDate, 'yyMMddHHmm')}.git${applicationRevision}" : ""
  applicationVersionFull = "${applicationVersion}${applicationVersionSnapshot}"
}

jar {
    baseName = 'myapp'
    version = '0.9.0'
}

sourceCompatibility = 1.8
targetCompatibility = 1.8

dependencies {

    compile group: 'com.sun.mail', name: 'javax.mail', version: '1.5.2'
    compile group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.3.6'
    compile group: 'commons-cli', name:'commons-cli', version: '1.3.1'
    compile group: 'org.json', name:'json', version: '20140107'

    compile "commons-codec:commons-codec:1.10"

    compile("org.springframework.boot:spring-boot-starter-hateoas")
    compile("org.springframework.boot:spring-boot-starter-web")
    compile("org.springframework.boot:spring-boot-starter-thymeleaf")
    compile("org.springframework.boot:spring-boot-starter-mail")
    compile("org.springframework.boot:spring-boot-starter-security")
    compile("org.springframework:spring-web")
    compile("org.springframework:spring-messaging")
    compile("joda-time:joda-time:2.2")
    compile("com.fasterxml.jackson.core:jackson-databind")
    compile("com.googlecode.json-simple:json-simple")
    compile("org.jdom:jdom:2.0.0")
    compile("org.hibernate:hibernate-validator")
    compile("org.apache.tomcat.embed:tomcat-embed-el")
    compile("org.apache.commons:commons-io:1.3.2")
    compile("org.kamranzafar:jtar:2.3")
    compile("org.thymeleaf.extras:thymeleaf-extras-springsecurity4")
    compile("com.jcraft:jsch:0.1.53")
    compile("javax.jmdns:jmdns:3.4.1")
    testCompile("org.springframework.boot:spring-boot-starter-test")


}

task wrapper(type: Wrapper) {
    gradleVersion = '2.14'
}

person Mark Underwood    schedule 16.08.2016    source источник
comment
Еще одна странность, которая может быть связана и, по-видимому, указывает на какую-то ошибку пользователя/группы/разрешений... когда я просматриваю zip-файл, он оказывается в пользовательской/групповой службе приложений/службе приложений. когда я пытаюсь chgrp файлы сгруппировать ip, я получаю, что операция не разрешена, даже если пользовательский сервис приложений является членом как группы pi, так и группы приложений... как подтверждено информационным сервисом   -  person Mark Underwood    schedule 16.08.2016
comment
Если вы хотите и можете переключиться на systemd для управления своим приложением, взгляните на этот ответ: stackoverflow.com/a/22121547 /272180   -  person yglodt    schedule 16.08.2016
comment
ДА! Кажется, это сработало отлично, yglodt. Спасибо.   -  person Mark Underwood    schedule 17.08.2016
comment
Если вы опубликуете это как ответ, я приму это. Я до сих пор не знаю, важно это или нет, просто хочу отдать вам должное за решение моей проблемы.   -  person Mark Underwood    schedule 17.08.2016
comment
Я разместил ответ, адаптированный к вашему случаю.   -  person yglodt    schedule 17.08.2016


Ответы (1)


Я бы рекомендовал запускать и управлять вашим приложением с помощью systemd.

Это позволяет очень легко запускать приложение под конкретным пользователем.

Для этого выполните следующие действия:

Сначала создайте файл определения службы /etc/systemd/system/myapp.service со следующим содержимым:

[Unit]
Description=My App

[Service]
User=nobody
# The configuration file application.properties should be here:
WorkingDirectory=/home/appservice/myapp/files 
ExecStart=/usr/bin/java -Xmx256m -jar myapp.jar
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Затем сообщите systemd о новом сервисном файле:

systemctl daemon-reload

и включите его, чтобы он работал при загрузке:

systemctl enable myapp.service

В конце вы можете использовать следующие команды для запуска/остановки вашего нового сервиса:

systemctl start myapp
systemctl stop myapp
person yglodt    schedule 17.08.2016