O Debian 11 traz o gnome-tweaks 3.34 que tem um menu de barra "Top Bar". Eu particularmente confio na opção "Seconds". Essa atualização regular da tela me ajuda a ter confiança de que uma conexão VNC ainda não foi desconectada.
Estou atualizando a frota para o Debian 13 que vem com o gnome-tweaks 46.1. Percebi que não há um menu "Top Bar".
Isso foi movido para algum lugar? Estou tentando encontrar algo nas notas de lançamento do upstream , mas o único lançamento no gitlab tem 7 anos.
À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:
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.| more.
git checkout.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:
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.
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ção | inotify Eventos |
|---|---|
touch file |
IN_OPEN |
echo "data" > file |
IN_MODIFY, IN_OPEN, IN_ACCESS, entãoIN_CLOSE_NOWRITE |
nano file(em aberto) |
IN_OPEN |
nano file(sobre ^O) |
IN_MODIFY, IN_CLOSE_WRITE, IN_OPEN,IN_ACCESS |
vim file(em aberto) |
IN_OPEN,IN_CLOSE_NOWRITE |
vim file(sobre :w) |
IN_MOVE_SELF, IN_ATTRIB, então os eventos param de vir deste arquivo |
gedit file(em aberto) |
IN_OPEN, IN_CLOSE_NOWRITE,IN_ACCESS |
gedit file(ao salvar) |
IN_OPEN, IN_CLOSE_WRITE, IN_ATTRIB, então os eventos param de vir deste arquivo |
mv newfile file |
IN_ATTRIB, então os eventos param de vir deste 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:
ClosedFeedback"In Progress"NewRejectedResolvedO 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 geraca-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).
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
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)
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:
Eu gostaria que os usuários do grupo foogrouppudessem:
systemctl start foo.service,systemctl stop foo.service,systemctl status foo.service, ejournalctl -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:
barpode ser iniciado, interrompido ou recarregado sem afetarfooSe /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?