Вопросы Теги

Какие данные передаются в Canonical для livepatch?

Execstop и Execstart изменились в обратном направлении

Согласно этому Unix & amp; Ответ на Linux: как запустить скрипт с systemd перед выключением, Execstop и Execstart будут отменены.

Строки: 

ExecStop=/bin/true
ExecStart=/bin/bash  /home/upload.sh

Должно читать:

В дальнейшем упоминается перезапуск служб. Поэтому после создания файла убедитесь, что systemctl daemon-reload и systemctl enable yourservice --now

Альтернативный метод не работает

before=, requires=, и т. д. иногда могут вводить в заблуждение. Вместо этого вы можете поместить свой скрипт в каталог /usr/lib/systemd/system-shutdown/. Он будет запущен сразу после выключения. См.: Как запустить скрипт с systemd прямо перед выключением

Префикс /usr может быть другим в некоторых системах, то есть просто запустите имя каталога с помощью /lib. 10]

7
задан 17 May 2018 в 14:09

3 ответа

Учитывая, что клиент livepatch является собственностью, у меня нет полного ответа.

При этом клиент (/snap/canonical-livepatch/*/canonical-livepatchd) записывается в Go. Отладка с Delve, вот некоторая информация для начала: 

(dlv) bt
0  0x00000000006ad140 in main.(*client).check
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:212
1  0x00000000006acfeb in main.(*client).Check
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:200
2  0x00000000006b8415 in main.refresh
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:60
3  0x00000000006bf957 in main.newDaemon.func1
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/daemon.go:76
4  0x00000000006b86a3 in main.(*refreshLoop).loop
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:120
5  0x00000000006c0bfd in main.(*service).Start.func1
   at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/service.go:151
6  0x0000000000457b31 in runtime.goexit
   at /home/c/.gobrew/versions/1.10/src/runtime/asm_amd64.s:2361
(dlv) locals
rendered.cap = 0
rendered.len = 0
rendered.ptr = *uint8 nil
status = main.ClientStatus {ClientVersion: "8.0.1", MachineId: "bfcf169468f641528ac653c41ff1797d", MachineToken: "",...+7 more}
(dlv) print status
main.ClientStatus {
    ClientVersion: "8.0.1",
    MachineId: "bfcf169468f641528ac653c41ff1797d",
    MachineToken: "",
    Architecture: "x86_64",
    CpuModel: "Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz",
    LastCheck: time.Time {
        wall: 0,
        ext: 0,
        loc: *time.Location nil,},
    BootTime: time.Time {
        wall: 0,
        ext: 63662149770,
        loc: *(*time.Location)(0x963f60),},
    ApplyTime: time.Time {
        wall: 0,
        ext: 0,
        loc: *time.Location nil,},
    Uptime: 3472,
    Kernels: []main.KernelStatus len: 1, cap: 1, [
        (*main.KernelStatus)(0xc4201883c0),
    ],}

Поля в переменной status:

Идентификатор машины версии клиента (значение от /etc/machine-id) Machine Token (Ubuntu One token?) Модель процессора и (OS?) Архитектура Последнее время проверки Время загрузки (время, затрачиваемое на загрузку?) Применить время (? - возможно, когда последнее обновление было применено?) Uptime Список ядер

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

Опять же, это отправная точка. Сделайте это так, как хотите, и, надеюсь, кто-то еще сможет предоставить более определенную информацию.

Как я могу быть уверен, что он не изменится внезапно, чтобы передать больше, чем я хочу?

Вы не можете. Исходный код недоступен, а привязки автоматически обновляются, IIRC.

8
ответ дан 22 May 2018 в 10:47
  • 1
    Интересно, что он говорит в вашей ссылке «Этот идентификатор однозначно идентифицирует хост. Его следует рассматривать как «конфиденциальный» и не должны подвергаться воздействию в ненадежных средах, в частности в сети. Интересно, будет ли livepatch работать, если я буду менять идентификатор машины регулярно. – Sebastian Stark 18 May 2018 в 08:51
  • 2
    @SebastianStark, так как livepatch бесплатно для трех систем для сообщества, я бы предположил, что он должен работать как минимум на три изменения. Не уверен, что произойдет после этого. – muru 18 May 2018 в 08:54
  • 3
    Я думаю, что никогда не узнаю, я не думаю, что мой работодатель когда-либо позволял мне подписывать это соглашение в любом случае. – Sebastian Stark 18 May 2018 в 09:05
  • 4
    Вы, вероятно, не должны были награждать эту награду так скоро. Возможно, кто-то другой, возможно, лучше справился бы с помощью внутренних дел. – muru 18 May 2018 в 09:09
  • 5
    Возможно Вы правы. Хотя я надеюсь, что люди здесь не только сделают это для (маленькой) щедрости. Я думаю, что этот вопрос очень важен. – Sebastian Stark 18 May 2018 в 15:29

Учитывая, что клиент livepatch является собственностью, у меня нет полного ответа.

При этом клиент (/snap/canonical-livepatch/*/canonical-livepatchd) записывается в Go. Отладка с Delve, вот некоторая информация для начала:

(dlv) bt 0 0x00000000006ad140 in main.(*client).check at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:212 1 0x00000000006acfeb in main.(*client).Check at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:200 2 0x00000000006b8415 in main.refresh at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:60 3 0x00000000006bf957 in main.newDaemon.func1 at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/daemon.go:76 4 0x00000000006b86a3 in main.(*refreshLoop).loop at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:120 5 0x00000000006c0bfd in main.(*service).Start.func1 at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/service.go:151 6 0x0000000000457b31 in runtime.goexit at /home/c/.gobrew/versions/1.10/src/runtime/asm_amd64.s:2361 (dlv) locals rendered.cap = 0 rendered.len = 0 rendered.ptr = *uint8 nil status = main.ClientStatus {ClientVersion: "8.0.1", MachineId: "bfcf169468f641528ac653c41ff1797d", MachineToken: "",...+7 more} (dlv) print status main.ClientStatus { ClientVersion: "8.0.1", MachineId: "bfcf169468f641528ac653c41ff1797d", MachineToken: "", Architecture: "x86_64", CpuModel: "Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz", LastCheck: time.Time { wall: 0, ext: 0, loc: *time.Location nil,}, BootTime: time.Time { wall: 0, ext: 63662149770, loc: *(*time.Location)(0x963f60),}, ApplyTime: time.Time { wall: 0, ext: 0, loc: *time.Location nil,}, Uptime: 3472, Kernels: []main.KernelStatus len: 1, cap: 1, [ (*main.KernelStatus)(0xc4201883c0), ],}

Поля в переменной status:

Идентификатор машины версии клиента (значение от /etc/machine-id) Machine Token (Ubuntu One token?) Модель процессора и (OS?) Архитектура Последнее время проверки Время загрузки (время, затрачиваемое на загрузку?) Применить время (? - возможно, когда последнее обновление было применено?) Uptime Список ядер

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

Опять же, это отправная точка. Сделайте это так, как хотите, и, надеюсь, кто-то еще сможет предоставить более определенную информацию.

Как я могу быть уверен, что он не изменится внезапно, чтобы передать больше, чем я хочу?

Вы не можете. Исходный код недоступен, а привязки автоматически обновляются, IIRC.

8
ответ дан 17 July 2018 в 14:33

Учитывая, что клиент livepatch является собственностью, у меня нет полного ответа.

При этом клиент (/snap/canonical-livepatch/*/canonical-livepatchd) записывается в Go. Отладка с Delve, вот некоторая информация для начала:

(dlv) bt 0 0x00000000006ad140 in main.(*client).check at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:212 1 0x00000000006acfeb in main.(*client).Check at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/client.go:200 2 0x00000000006b8415 in main.refresh at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:60 3 0x00000000006bf957 in main.newDaemon.func1 at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/daemon.go:76 4 0x00000000006b86a3 in main.(*refreshLoop).loop at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/refresh.go:120 5 0x00000000006c0bfd in main.(*service).Start.func1 at /home/c/Canonical/go/livepatch/src/github.com/CanonicalLtd/livepatch-client/parts/canonical-livepatch/build/daemon/service.go:151 6 0x0000000000457b31 in runtime.goexit at /home/c/.gobrew/versions/1.10/src/runtime/asm_amd64.s:2361 (dlv) locals rendered.cap = 0 rendered.len = 0 rendered.ptr = *uint8 nil status = main.ClientStatus {ClientVersion: "8.0.1", MachineId: "bfcf169468f641528ac653c41ff1797d", MachineToken: "",...+7 more} (dlv) print status main.ClientStatus { ClientVersion: "8.0.1", MachineId: "bfcf169468f641528ac653c41ff1797d", MachineToken: "", Architecture: "x86_64", CpuModel: "Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz", LastCheck: time.Time { wall: 0, ext: 0, loc: *time.Location nil,}, BootTime: time.Time { wall: 0, ext: 63662149770, loc: *(*time.Location)(0x963f60),}, ApplyTime: time.Time { wall: 0, ext: 0, loc: *time.Location nil,}, Uptime: 3472, Kernels: []main.KernelStatus len: 1, cap: 1, [ (*main.KernelStatus)(0xc4201883c0), ],}

Поля в переменной status:

Идентификатор машины версии клиента (значение от /etc/machine-id) Machine Token (Ubuntu One token?) Модель процессора и (OS?) Архитектура Последнее время проверки Время загрузки (время, затрачиваемое на загрузку?) Применить время (? - возможно, когда последнее обновление было применено?) Uptime Список ядер

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

Опять же, это отправная точка. Сделайте это так, как хотите, и, надеюсь, кто-то еще сможет предоставить более определенную информацию.

Как я могу быть уверен, что он не изменится внезапно, чтобы передать больше, чем я хочу?

Вы не можете. Исходный код недоступен, а привязки автоматически обновляются, IIRC.

8
ответ дан 20 July 2018 в 14:38

Другие вопросы по тегам:

Похожие вопросы: