Às vezes, se eu git checkout, ou mesmo make, acabo com alguma saída inesperada que me faz perguntar:

Espera, o quê? Vamos ver isso de novo.

Minhas opções geralmente são:

1. Movo minha mão para o mouse e começo a rolar no terminal.
   • Para comandos como dpkg-buildpackageesse, que falham devido a um cmakeerro de configuração, eles imprimem uma quantidade enorme de dados de depuração após o erro, então você REALMENTE tem que rolar muito para trás.
2. Execute o comando novamente através de | more.
   • mas isso não funciona bem para comandos que alteram seu estado local, como git checkout.
   • é menos útil para comandos que demoram muito para serem concluídos.

Existe um terminal que facilita a navegação pela saída de comandos anteriores?

Não consigo completeoferecer sugestões completas quando as opções ${COMPREPLY[@]}contêm um :caractere. Em vez disso, oferece apenas o prefixo comum a todas as sugestões.

Aqui está um exemplo que funciona bem:

_foo()
{
  local cur=${COMP_WORDS[$COMP_CWORD]}
  COMPREPLY=( $(compgen -W "bart baze" -- "$cur" ) )
}
complete -F _foo foo

E aqui está como é usado (nunca pressiono Enter, apenas TABonde indicado)

$ foo <tab>
$ foo ba       <-- Autocompletes common prefix, good

$ foo ba<tab>
bart baze      <-- Suggests options, good

$ foo bar<tab>
$ foo bart     <-- Autocompletes the only option, good

Mas se eu acrescentar algo com a :, like http://, ele não fornecerá sugestões completas (apenas o prefixo comum a todas as opções):

$ _foo()
{
  local cur=${COMP_WORDS[$COMP_CWORD]}
  COMPREPLY=( $(compgen -W "h:bart h:baze" -- "$cur" ) )
}
$ complete -F _foo foo

$ foo <tab>
$ foo h:ba         <-- Autocompletes common prefix, good

$ foo h:ba<tab>
$ foo h:ba         <-- No effect

O manual sugere algo sobre -Icomo trabalhar com delimitadores, mas complete -I -F _foo foonão muda nada.

Se eu inspecionar mais profundamente, parece que é como complete -Finterpreta ${COMPREPLY[@]}. compgenparece estar COMPREPLYbem.

$ COMPREPLY=( $(compgen -W "h:bart h:baze" -- h) )
$ for i in "${COMPREPLY[@]}"; do echo "$i"; done
h:bart
h:baze

Eu tenho um script com este uso:

myscript [options] positional-args... -- [fwd-params]

Como [options]pode ter variantes longas ou curtas, gosto de usar arquivos getopt. Mas estou tendo problemas.

Eu uso getoptassim:

args=$(getopt -o a:,b --long alpha:,gamma -- "$@")
eval set -- "$args"
while : ; do 
  case "$1" in
    -a | --alpha) a="$2" ; shift 2 ;; 
    -b          ) b=true ; shift   ;;
    --gamma     ) g=true ; shift   ;;
    -- )          shift  ; break   ;; 
  esac
done

positionals=()
while [ $# -gt 0 ] ; do
  case "$1" in
    *  ) positionals+=("$1"); shift ;;
    -- ) shift ; break ;;
  esac
done

# What-ever is left in "$@" needs to be forwarded to another program

backend "$@"

Isso funciona muito bem se eu não tiver nenhum [fwd-params]:

$ getopt -o a:,b -- -a 1 -b pos1 pos2
 -a '1' -b -- 'pos1' 'pos2'
            ^-- getopt adds this to help me find 
                the end-of-options/start-of-positionals

Mas desmorona se o usuário definir algum arquivo [fwd-params]. Aqui está minha saída desejada:

$ getopt -o a:,b -- -a 1 -b pos1 pos2 -- fwd1
 -a '1' -b -- 'pos1' 'pos2' '--' 'fwd1'
                              ^
                              \-   I'll use this to delimit 
                                   the positional arguments 
                                   from the forwarding ones.

E aqui está o que eu realmente entendo. A intenção do usuário --foi filtrada.

$ getopt -o a:,b -- -a 1 -b pos1 pos2 -- fwd1
 -a '1' -b -- 'pos1' 'pos2' 'fwd1'

Qual é a melhor maneira de delimitar meus argumentos posicionais dos de encaminhamento?

Tive problemas com pessoas fazendo login em alguns servidores via ssh e esquecendo que um terminal específico não é mais local. Hoje alguém tentou desligar seu laptop sudo shutdown -h nowe acidentalmente derrubou um servidor.

Eu gostaria de mudar a cor do bash PS1nesses servidores quando estiver logado via ssh. Eu controlo esses servidores através de um pacote debian que envio para eles.

Qual é a melhor maneira de implementar um padrão PS1 em todo o site?

A resposta óbvia é criar um arquivo /etc/profile.d/sshcolourscom este conteúdo para deixar o user@host roxo:

if [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ] ; then
    PS1='\[\033[01;35m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
fi

bashirá ler isso via /etc/profile(quais fontes /etc/profile.d/*). No entanto, mais tarde ele lerá ~/.bashrco que provavelmente será substituído PS1com base $TERMno definido em /etc/skel/.bashrc.

Existe alguma maneira de arquivar sourcemeu site em todo o site ~/.bashrcsem tocar ~/.bashrce sem forçar minha equipe a adotar uma mudança no lado do cliente?

Aqui estão algumas ideias ruins:

1. Depois de definir $PS1, ~/.bashrccondicionalmente fontes /usr/share/bash-completion/completions/*, para que eu pudesse colocar meu arquivo lá. Mas alguns testes me mostraram que a condição não foi atendida ou /usr/share/bash-completion/bash_completionreverteu o ambiente.

2. Em postinsteu poderia anexar uma linha para fornecer meu arquivo ao arquivo ~/.bashrc. Isso parece ilegal e problemático:

for h in /home/*; do
    if [ ! grep -q profile_amendments "$h/.bashrc" ] ; then
        echo ". /etc/profile_amendments" >> "$h/.bashrc"
    fi
done

Gostaria de monitorar um arquivo com inotifye acionar algum código quando alguém altera o conteúdo ( IN_MODIFYou IN_CLOSE_WRITE), mas estou tendo problemas onde inotifypara de retornar eventos quando os usuários editam o arquivo com sua ferramenta favorita. O arquivo deve ser simples (linha única, sem espaços, no máximo 20 caracteres). Prefiro não restringir seu uso, mas não sei como lidar com diferentes situações.

Estou usando inotifye estes são os eventos que recebo quando vários aplicativos editam o arquivo:

A certa altura, pensei ter visto gedito gatilho também disparar IN_DELETE_SELFantes de ficar em silêncio.

No caso em que um usuário usa vime gedit, paro de receber inotifyeventos depois que o usuário termina as edições. Como devo lidar com isso?

A única coisa que vejo em comum é o IN_ATTRIBevento. Suspeito que quando receber o IN_ATTRIBevento, devo fazer inotify_rm_watch()isso wde depois recriar um novo inotify_add_watch()com base no mesmo caminho. Mas essa é a abordagem correta?

Outra opção poderia ser observar o diretório pai. O nome do arquivo afetado está incluído no arquivo inotify_event::namee, portanto, eu poderia filtrar o arquivo de interesse e acionar qualquer um IN_MODIFYou IN_CLOSE_WRITEonde namecorresponda ao meu arquivo de interesse.

Estou adicionando o bash-completion a uma ferramenta existente.

Depois que alguém passar a -sbandeira, gostaria de oferecer várias opções de conclusão do bash:

• Closed
• Feedback
• "In Progress"
• New
• Rejected
• Resolved

O espaço "In Progress"está causando um problema.

#!/usr/bin/env bash
_remote-redmine()
{
    local cur

    COMPREPLY=()
    cur=${COMP_WORDS[$COMP_CWORD]}

    case "${COMP_WORDS[($COMP_CWORD-1)]}" in
        -s)
            s_opts=( "New" "In Progress" "Resolved" "Feedback" "Closed" "Rejected" )
            COMPREPLY=( $( compgen -W "${s_opts[*]}" -- "$cur") )
            ;;
    esac
    return 0
}
complete -F _remote-redmine remote-redmine

Quando executo a ferramenta, recebo:

$ remote-redmine -s <tab><tab>
Closed    Feedback  In        New       Progress  Rejected  Resolved

Mas eu gostaria de obter:

$ remote-redmine -s <tab><tab>
Closed    Feedback  "In Progress"       New       Rejected  Resolved

ou

$ remote-redmine -s <tab><tab>
Closed    Feedback  In\ Progress        New       Rejected  Resolved

Coisas que tentei:

• s_opts=( ... "In\ Progress" ... ): Sem diferença

• s_opts( ... "In\\ Progress" ...): Sem diferença

• s_opts( ... "In\\\ Progress" ...): Duas opções são In\eProgress

• s_opts( ... "\"In Progress\"" ...): Sem diferença

• compgen -o nospace ...: Sem diferença

• compgen -o noquote ...: Sem diferença

• Pelo menos compgenpode colocar In Progressuma linha, mas isso não se traduz emcomplete

  $ compgen -W 'New "In Progress"'
  New
  In Progress
  

• Escapar de aspas extras ajuda compgen, mas isso não se traduz em complete:

  $ compgen -W 'New "\"In Progress\""'
  New
  "In Progress"
  

• Escapar do espaço três vezes ajuda, mas ainda não se traduz em complete:

  $ compgen -W 'New In\\\ Progress'
  New
  In\ Progress
  

• Achei que escapar do espaço sete vezes seria promissor porque resolveria completealguns deles, mas isso também não ajudou:

  $ compgen -W 'New In\\\\\\\ Progress'
  New
  In\\\ Progress
  ...
  $ remote-redmine -s <tab><tab>
  ...   In\\\  New  Progress ...
  

• Ignorar compgenfuncionará, mas perco o preenchimento automático em guias únicas e a filtragem em guias duplas

  COMPREPLY=( ... 'In\ Progress' ... )
  COMPREPLY=( ,,, '"In Progress"' ... )
  

Eu tenho uma licença com a qual estou assinando:

gpg --default-sig-expire "2024-02-14" --sign licence

Isto resulta em:

$ gpg --verify licence.gpg
gpg: Signature made Tue 13 Feb 2024 08:18:39 AM CET
gpg:                using RSA key 1234567890ABCDEF1234567890ABCDEF
gpg:                issuer "[email protected]"
gpg: Good signature from "Stewart <[email protected]>" [ultimate]
gpg: Signature expires Wed 14 Feb 2024 12:00:00 PM CET

Esse 12:00:00 PM CETé o meu problema. Geralmente vou almoçar nesse horário. Prefiro não receber ligações sobre sistemas off-line enquanto estou almoçando. É possível especificar o horário? Prefiro que expire em 13:00:00 PM CET.

--ask-sig-expiresolicita apenas o número de dias/semanas/anos:

$ gpg --ask-sig-expire --sign licence
Please specify how long the signature should be valid.
         0 = signature does not expire
      <n>  = signature expires in n days
      <n>w = signature expires in n weeks
      <n>m = signature expires in n months
      <n>y = signature expires in n years
Signature is valid for? (0) 

ISO 8601 não parece compatível:

$ gpg --default-sig-expore "2024-02-14T13:00:00+02:00" --sign licence
gpg: '2024-02-14T13:00:00+02:00' is not a valid signature expiration

A man systemd.timeespecificação não parece suportada

$ gpg --default-sig-expire "2024-02-14 13:00:00" --sign licence
gpg: '2024-02-14 13:00:00' is not a valid signature expiration

A página de manual também não sugere que um momento seja possível:

--default-sig-expire
       The default expiration time to use for signature expiration. Valid values 
       are "0" for no expiration, a number followed by the letter d (for days), 
       w (for weeks), m (for months), or  y (for years) (for example "2m" for two 
       months, or "5y" for five years), or an absolute date in the form 
       YYYY-MM-DD. Defaults to "0".

A única solução que encontrei foi alterar o fuso horário do meu sistema para o próximo fuso horário a oeste de mim, assinar e definir o fuso horário do meu sistema de volta ao meu horário original.

$ sudo mv /etc/localtime{,.backup} 
$ sudo ln -s /usr/share/zoneinfo/Europe/London /etc/localtime
$ gpg --default-sig-expire "2024-02-14" --sign licence
$ sudo mv /etc/localtime{.backup,}
$ gpg --verify licence.gpg
gpg: Signature made Tue 13 Feb 2024 08:18:39 AM CET
gpg:                using RSA key 1234567890ABCDEF1234567890ABCDEF
gpg:                issuer "[email protected]"
gpg: Good signature from "Stewart <[email protected]>" [ultimate]
gpg: Signature expires Wed 14 Feb 2024 01:00:05 PM CET

Temos uma autoridade de certificação (CA) privada que é usada apenas em sites da nossa intranet.

Posso obter o certificado facilmente:

openssl s_client -showcerts -connect atlas.sim.local:8443 </dev/null 2>/dev/null|openssl x509 -outform PEM >atlas.crt

Gostaria que meus dispositivos Debian confiassem automaticamente nesta autoridade de certificação. Eu tenho aptum repositório privado e todos os meus dispositivos Debian possuem pacotes deste repositório instalados. Portanto, gostaria que este *.crtarquivo fosse implantado neste pacote.

O pacote efetivamente fará isso:

install -Dm644 atlas.crt /usr/share/ca-certificates/sim.local/atlas.crt

Mas como faço para regenerar os certificados ca depois que esse arquivo for implantado? Estou procurando um arquivo para implantar ou uma linha em que possa executar postinst.

Meu primeiro pensamento foi simplesmente:

/usr/sbin/update-ca-certificates

mas man update-ca-certificatesdiz:

update-ca-certificatesé um programa que atualiza o diretório /etc/ssl/certspara conter certificados SSL e gera ca-certificates.crt...

Ele lê o arquivo /etc/ca-certificates.conf. Cada linha fornece um nome de caminho de um certificado CA no /usr/share/ca-certificatesqual deve ser confiável.

Para que isso funcione, preciso garantir sim.local/atlas.crtque esteja no formato /etc/ca-certificates.conf. Infelizmente não há nada /etc/ca-certificates.conf.d/que me permita inserir outro arquivo com esse conteúdo.

Se eu ler /etc/ca-certificates.conf, diz:

# This file lists certificates that you wish to use or to ignore to be
# installed in /etc/ssl/certs.
# update-ca-certificates(8) will update /etc/ssl/certs by reading this file.
#
# This is autogenerated by dpkg-reconfigure ca-certificates.

Portanto, eu poderia tentar:

dpkg-reconfigure ca-certificates

Mas isso faz com que apareça uma caixa de diálogo interativa com meu certificado desmarcado por padrão. Prefiro que não seja interativo.

Este é o meu atual postinst. mas não tenho certeza se é a solução certa. Existe uma maneira certa de fazer isso?

#!/bin/bash

set -e

case "$1" in
  configure)

    if [ -e /etc/ca-certificates.conf ] && 
      ! grep -q sim.local/atlas.crt /etc/ca-certificates.conf; then

        printf "%s\n" sim.local/atlas.crt >> /etc/ca-certificates.conf;
        /usr/sbin/update-ca-certificates;
    fi
  ;;
esac

Eu tenho isso na minha máquina:

$ cat /etc/profile.d/proxy.sh 
export http_proxy=http://192.168.1.30:3128
export https_proxy=https://192.168.1.30:3128

Isso funciona muito bem, até que preciso usar uma interface HTTP com um aplicativo no localhost.

$ wget localhost
--2023-03-02 06:54:52--  http://localhost/
Connecting to 192.168.1.30:3128... connected.
Proxy request sent, awaiting response... 503 Service Unavailable
2023-03-02 06:54:52 ERROR 503: Service Unavailable.

$ wget 127.0.0.1
--2023-03-02 06:55:20--  http://127.0.0.1/
Connecting to 192.168.1.30:3128... connected.
Proxy request sent, awaiting response... 403 Forbidden
2023-03-02 06:55:20 ERROR 403: Forbidden.

Existe uma maneira de evitar localhostque as 127.0.0.1solicitações sejam encaminhadas para o proxy?

Detalhes:

Esta máquina não está conectada diretamente à internet. Não possui gateway ou rota padrão. Mas está em uma LAN com uma máquina proxy (192.168.1.30) que possui um servidor proxy instalado (porta 3128) e possui uma conexão com a Internet.

$ ip addr
1: lo: ...
    inet 127.0.0.1/8 scope host lo
2: eno1: ...
    altname enp24s0f0
    inet 192.168.1.100/24 brd 192.168.1.255 scope global eno1

$ ip route
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100

$ cat /etc/hosts
127.0.0.1   localhost

$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
    address 192.168.1.100
    netmask 255.255.255.0

Eu gostaria de instalar um serviço de um *.debpacote, vinculá-lo usando update-alternatives. Em seguida, habilite/inicie o link simbólico. Existem alguns exemplos disso no arquivo debian existente? Se não, como alguém faria isso?

Estou fazendo isso porque quero poder implantar várias versões do meu software na mesma máquina e usar update-alternativespara escolher qual delas é executada.

Arquivos de controle típicos podem ser assim para algo que usa update-alternativese depende do debhelper para serviços:

# myapp99.postinst
update-alternatives --install \
    /lib/systemd/system/myapp.service myapp \
    /lib/systemd/system/myapp99.service 99

#DEBHELPER#

# myapp99.prerm
update-alternatives --remove myapp lib/systemd/system/myapp99.service

#DEBHELPER#

Mas o problema aqui é operar #DEBHELPER#depois que eu já o tiver feito.myapp.servicepostrmupdate-alternatives --remove

Eu poderia mover meu update-alternatives --removepara depois #DEBHELPER#no postrm, mas ainda teria um problema em que a limpeza de um pacote antigo não utilizado pararia/desativaria myapp.service. Tenho certeza de que há outras coisas que não estou considerando também.

Existem pacotes no arquivo debian existente que fazem o que estou tentando fazer?

Estou quase pensando em fazer isso sem debhelper: Verificar se o link existe antes da instalação e habilitar se for novo. Verificando se o link existe após a limpeza, e parando/desabilitando/mascarando somente se este foi o último fornecedor daquele serviço. Se esse é o único caminho a seguir, tudo bem... Eu prefiro não reinventar a roda e introduzir bugs.

Estou tentando me conectar a uma câmera wifi externa de segunda mão. Ele tem um slot ethernet e um adesivo com o endereço MAC, mas nenhuma outra marca ou modelo/número de série.

Estou tentando encontrar seu endereço IP.

Meu plano atual é conectar um cabo ethernet diretamente entre minha máquina e esta câmera e, em seguida, digitalizar todos os intervalos IPv4 privados reservados com nmap:

ip addr add 10.0.0.1/8 dev eno2
ip addr add 172.16.0.1/12 dev eno2
ip addr add 192.168.0.1/16 dev eno2

nmap -sn 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8

Mas isso pode levar muito tempo (acho que cerca de 74 horas) e não posso ter certeza de que este dispositivo não está usando IPv6. Existe uma solução melhor?

Eu tenho uma GUI onde ActiveStatemostro vários serviços do systemd.

Em 10Hz, uso a API sd-bus para consultar cada serviço assim:

sd_bus* bus;
sd_bus_error err = SD_BUS_ERROR_NULL;
char* msg = 0;

sd_bus_default_system(&bus);

sd_bus_get_property_string(bus,
    "org.freedesktop.systemd1",
    "/org/freedesktop/systemd1/unit/foo_2eservice",
    "org.freedesktop.systemd1.Unit",
    "ActiveState",
    &err,
    &msg);

Meu problema é que quando executo esse código, /sbin/initou /lib/systemd/systemd-logindconsome cerca de 50% da CPU. A criação de perfil do código mostra uma enorme quantidade de tempo consumido pelo sd_bus_get_property_string. Preciso reduzir o número de vezes que chamo essa função.

A introspecção da interface d-bus é interessante:

busctl introspect \
    org.freedesktop.systemd1 \
    /org/freedesktop/systemd1/unit/foo_2eservice \
    org.freedesktop.system1.Unit

NAME                             TYPE      SIGNATURE RESULT/VALUE   FLAGS
.Kill                            method    si        -     -
.Ref                             method    -         -     -
.Reload                          method    s         o     -
.ReloadOrRestart                 method    s         o     -
.ReloadOrTryRestart              method    s         o     -
.ResetFailed                     method    -         -     -
.Restart                         method    s         o     -
.SetProperties                   method    ba(sv)    -     -
.Start                           method    s         o     -
.Stop                            method    s         o     -
.TryRestart                      method    s         o     -
.Unref                           method    -         -     -
.ActiveEnterTimestamp            property  t         0     emits-change
.ActiveEnterTimestampMonotonic   property  t         0     emits-change
.ActiveExitTimestamp             property  t         0     emits-change
.ActiveExitTimestampMonotonic    property  t         0     emits-change
.ActiveState                     property  s         "inactive"   emits-change
...

Isso me diz que a propriedade ActiveState emite uma alteração .

Como posso obter um descritor de arquivo ou tocar no loop de eventos para receber essa alteração?

A especificação D-Bus sugere que o systemd emitirá um org.freedesktop.DBus.Properties.PropertiesChangedsinal quando as propriedades mudarem. Acho que preciso descobrir como assinar esse sinal.

Estou tentando limpar alguns arquivos de memória compartilhada de lixo deixados por um serviço após a falha. O serviço é executado como um usuário do sistema e um grupo específico. Sou membro desse grupo, mas não consigo excluir a memória compartilhada.

$ ls -la /dev/shm
drwxrwxrwt  2 root   root        600 Jun 20 11:18 .
drwxr-xr-x 22 root   root       3680 Jun 19 12:43 ..
-rw-rw-rw-  1 simbot simusers 500032 Jun 20 10:35 Sim_SharedMem_SLM__data_0

$ groups | grep simusers -q && echo member || echo not member
member

$ rm -f /dev/shm/Sim_SharedMem_SLM__data_0 
rm: cannot remove '/dev/shm/Sim_SharedMem_SLM__data_0': Operation not permitted

Não tenho problemas para excluir os arquivos como root. Também não tenho problemas para excluir o arquivo se sou eu quem executa (e trava) o processo (sou o usuário que possui os arquivos).

Reprodução

Acho que a maneira mais fácil de exibir o problema é executar o processo como eu e alterar alguns dos arquivos de lixo como se fossem de propriedade do outro usuário.

$ /usr/local/bin/badProcess
^C

$ ls -la /dev/shm
drwxrwxrwt  2 root root     640 Jun 20 11:31 .
drwxr-xr-x 22 root root    3680 Jun 19 12:43 ..
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_0
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_1
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_2
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_3

$ sudo chown simbot          Sim_SharedMem_SLM__data_1
$ sudo chown       :simusers Sim_SharedMem_SLM__data_2
$ sudo chown simbot:simusers Sim_SharedMem_SLM__data_3

$ ls -la /dev/shm
drwxrwxrwt  2 root   root         640 Jun 20 11:31 .
drwxr-xr-x 22 root   root        3680 Jun 19 12:43 ..
-rw-rw-rw-  1 stew   stew      500032 Jun 20 11:31 Sim_SharedMem_SLM__data_0
-rw-rw-rw-  1 simbot stew      500032 Jun 20 11:31 Sim_SharedMem_SLM__data_1
-rw-rw-rw-  1 stew   simusers  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_2
-rw-rw-rw-  1 simbot simusers  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_3

$ rm /dev/shm/*
rm: cannot remove 'Sim_SharedMem_SLM__data_1`': Operation not permitted
rm: cannot remove 'Sim_SharedMem_SLM__data_3`': Operation not permitted

lsattr

Algumas soluções sugerem verificar os atributos +a ou +i com lsattr.

$ lsattr Sim_SharedMem_SLM__data_0
lsattr: Inappropriate ioctl for device While reading flags on Sim_SharedMem_SLM__data_0

Isso acontece porque esses atributos não são suportados pelo tmpfs (que é esse diretório)

$ mount | grep /dev/shm
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

ACLs

Dei uma olhada na ACL para ver se havia algo engraçado com o diretório pai ou o próprio arquivo. Não vejo que não aprendemos com ls Eu tenho permissões de gravação no diretório pai

$ getfacl /dev/shm
getfacl: Removing leading '/' from absolute path names
# file: dev/shm
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx

$ getfacl /dev/shm/Sim_SharedMem_SLM__data_0 
getfacl: Removing leading '/' from absolute path names
# file: dev/shm/Sim_SharedMem_SLM__data_0
# owner: simbot
# group: simusers
user::rw-
group::rw-
other::rw-

Eu tenho um único pacote fonte upstream usando cmake e gostaria de empacotá-lo como dois pacotes binários debian.

$ tree proj
proj/
├── app1.c
├── app2.c
└── CMakeLists.txt

O Upstream's CMakeLists.txtjá foi escrito com isso em mente. Eles usam o argumento COMPONENTS deinstall

$ cat proj/CMakeLists.txt
include(GnuInstallDirs)

add_executable(app1 app1.c)
install(
  TARGETS app1 
  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
  COMPONENT app1)

add_executable(app2 app2.c)
install(
  TARGETS app2
  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
  COMPONENT app2)

Para compilar/instalar localmente, é bem fácil:

$ mkdir build && cd build
$ cmake ../proj -DCMAKE_INSTALL_PREFIX=/usr/local  # Configure
$ cmake --build .                                  # Build
$ cmake -DCOMPONENT=app1 -P cmake_install.cmake    # Install app1 component
$ cmake -DCOMPONENT=app2 -P cmake_install.cmake    # Install app2 component

Mas como você construiria um debian/rulesarquivo para isso?

Como concedo permissão somente somegroupleitura para ler o diário do sistema? (Estou no Debian10 buster).

$ journalctl  
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
No journal files were opened due to insufficient permissions.

Eu sei que posso adicionar um usuário ao systemd-journalgrupo, mas como dou permissão de leitura a um grupo?

Eu tenho um script que se parece com isso:

#!/bin/bash
set -e 

tmpdir=$(mktemp -d)
pushd $tmpdir
trap 'popd && rm -rf $tmpdir' EXIT

# Business logic which may succeed or fail...
/bin/false

Quando sai, tudo popdbem, mas não remove o diretório temporário. Parece que $tmpdirnão se resolve na armadilha, mas como podemos superar isso?

Verifiquei que $tmpdirnão foi resolvido executando novamente o script sem -rfno arquivo rm. Que saiu com:

rm: missing operand 

em vez do esperado

rm: cannot remove '/tmp/tmp.Y1SdoY5dSu/': Is a directory

Estou tentando permitir que os usuários de um somegroupgerenciem o someunitserviço systemd.

Em polkit (>=0.106), isso pode ser feito adicionando regras:

/etc/polkit-1/rules.d/20-someunit.rules
---
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" 
        && subject.isInGroup("somegroup")
        && (action.lookup("unit") == "someunit.service") )
    {
        var verb = action.lookup("verb");
        if (verb == "start" || verb == "stop" || verb == "restart") {
            return polkit.Result.YES;
        }
    }
});

No entanto, estou no Debian stretch/buster onde estamos polkit 0.105desde 2012. polkit(<0.106)não suporta os rules.d/*arquivos. Em vez disso, contamos com /etc/polkit-1/localauthority/50-local.d/*.pkla.

Seguindo alguns exemplos em pklocalauthority(8) , consigo fazer a maior parte disso funcionar em um arquivo pkla equivalente:

/etc/polkit-1/localauthority/50-local.d/manage-units.pkla
----
[Allow users to manage services]
Identity=unix-group:somegroup
Action=org.freedesktop.systemd1.manage-units
ResultActive=yes

No entanto, isso concede acesso para TODAS as ações em TODOS os serviços. Existe um equivalente para permitir action.lookup()recursos específicos?

Eu experimentei systemctl enablee systemctl edit, dos quais ambos ainda falharam (isso é bom). Portanto, action.lookup("verb")pode não ser necessário, mas action.lookup("unit")ainda é bastante importante.

Há muitas perguntas sem resposta sobre este assunto:

• https://askubuntu.com/questions/536591
• https://askubuntu.com/questions/875522
• regra polkit não está funcionando

Eu gostaria que os usuários do grupo foogrouppudessem:

• systemctl start foo.service,
• systemctl stop foo.service,
• systemctl status foo.service, e
• journalctl -u foo.service

sem usar privilégios elevados. Isso é possível?

Eu tenho um serviço systemd que se parece com:

[Unit]
Description=foo service

[Service]
Type=simple
ExecStart=/bin/sleep infinity
User=foobot
Group=foogroup

Onde fooboté um usuário do sistema.

Eu sei que podemos instalar o arquivo de unidade ~/.config/systemd/user/para permitir que um usuário sem privilégios use o systemd, mas isso realmente não ajuda um grupo.

Nota: Eu planejo usar a API sd-buslibsystem-dev do cockpit , então adicionar systemctlnão /etc/sudoersvai ajudar.

Eu não me importo muito com systemctl enableisso, tudo bem se eu precisar de privilégios elevados para isso.

Estou criando um pacote fooque inicia/fecha o pacote upstream bar. A relação deve ser:

• Quando você inicia o foo, inicie também o bar.
• Quando você parar/recarregar foo, também pare/recarregue a barra.
• barpode ser iniciado, interrompido ou recarregado sem afetarfoo

Se /lib/systemd/system/bar.serviceparece com isso:

[Unit]
Description=Bar

[Service]
ExecStart=/bin/sleep infinity
Restart=on-failure

Então, a solução "normal" seria adicionar WantedBye PartOfrelacionamentos a bar:

[Unit]
Description=Bar
PartOf=foo.service

[Service]
ExecStart=/bin/sleep infinity
Restart=on-failure

[Install]
WantedBy=foo.service

No entanto, baré um pacote upstream e acho que não é certo forçar bara estar ciente fooou corrigir bar.

Eu pensei que uma solução perfeita seria criar foo.serviceassim:

[Unit]
Description=Foo
Wants=bar.service
ConsistsOf=bar.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes

No entanto, meu journalctl diz:

Valor l desconhecido 'ConsistsOf' na seção 'Unidade'

e as páginas man dizem:

Quando PartOf=b.service é usado em a.service, essa dependência será mostrada como ConsistsOf=a.service na listagem de propriedades de b.service. A dependência ConsistsOf= não pode ser especificada diretamente.

Não sei por ConsistsOf= que não pode ser especificado diretamente, mas existe uma alternativa que não considerei?

Estou tentando criar um arquivo *.deb do debian usando cmake com um compilador cruzado mingw. O teste do compilador do CMake falha ao usar o dpkg-buildpackage.

Construir normalmente é bom:

mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
         -DCMAKE_VERBOSE_MAKEFILE=ON 
         -DCMAKE_BUILD_TYPE=None 
         -DCMAKE_INSTALL_SYSCONFDIR=/etc 
         -DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /etc/alternatives/i686-w64-mingw32-gcc
-- Check for working C compiler: /etc/alternatives/i686-w64-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /etc/alternatives/i686-w64-mingw32-g++
-- Check for working CXX compiler: /etc/alternatives/i686-w64-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done

No entanto, quando eu construo isso usando dpkg-buildpackage, ele falha ao configurar:

dpkg-buildpackage -uc -us
dpkg-buildpackage: info: source package foo
dpkg-buildpackage: info: source version 1.0
dpkg-buildpackage: info: source distribution stretch
dpkg-buildpackage: info: source changed by $USER
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build hw
 fakeroot debian/rules clean
dh clean --buildsystem=cmake --parallel 
   dh_testdir -O--buildsystem=cmake -O--parallel
   dh_auto_clean -O--buildsystem=cmake -O--parallel
   dh_clean -O--buildsystem=cmake -O--parallel
 dpkg-source -b hw
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building sim-honeywell-ease-control in sim-honeywell-ease-control_1.0.tar.xz
dpkg-source: info: building sim-honeywell-ease-control in sim-honeywell-ease-control_1.0.dsc
 debian/rules build
make: 'build' is up to date.
 fakeroot debian/rules binary
dh binary --buildsystem=cmake --parallel 
   dh_testdir -O--buildsystem=cmake -O--parallel
   dh_update_autotools_config -O--buildsystem=cmake -O--parallel
   dh_auto_configure -O--buildsystem=cmake -O--parallel
    cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /etc/alternatives/i686-w64-mingw32-gcc
-- Check for working C compiler: /etc/alternatives/i686-w64-mingw32-gcc -- broken
CMake Error at /usr/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51 (message):
  The C compiler "/etc/alternatives/i686-w64-mingw32-gcc" is not able to
  compile a simple test program.

A parte interessante do log completo é uma falha durante a vinculação:

/etc/alternatives/i686-w64-mingw32-gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -Wl,-z,relro  -Wl,--whole-archive CMakeFiles/cmTC_fc912.dir/objects.a -Wl,--no-whole-archive  -o cmTC_fc912.exe -Wl,--out-implib,libcmTC_fc912.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/cmTC_fc912.dir/linklibs.rsp
/usr/bin/i686-w64-mingw32-ld: unrecognized option '-z'

O vinculador mingw não reconhece a -zopção. Quando eu diffo CMakeCache.txt, posso ver que dpkg-buildpakcage adiciona alguns sinalizadores de vinculador por padrão:

< CMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-z,relro
---
> CMAKE_EXE_LINKER_FLAGS:STRING=

Como posso evitar dpkg-buildpackagefazer isso?

FYI: meu debian/rulesarquivo se parece com isso:

#!/usr/bin/make -f
%:
    dh $@ --buildsystem=cmake --parallel