Parece que a pesquisa no Outlook 2019 (do Office Professional Plus) no Windows 10 está completamente quebrada ou terrivelmente documentada:

Eu tinha mensagens criadas automaticamente, e eu queria limpar algumas delas. Felizmente, elas têm um número de versão no assunto como "vX.YZ", então eu apenas tentei corresponder a uma versão específica (para marcar e excluir todas as mensagens correspondentes).

No entanto, ao pesquisar por v1.1.1Outlook também correspondeu v1.4.0e outros. Não consigo entender. Colocar a sequência de pesquisa entre aspas duplas não ajudou. Eu tentei as duas, pesquisa rápida e pesquisa estendida, sem diferenças no resultado.

Exemplo

Pesquisando por "v1.1.1", uma mensagem com o assunto pw-expiration/LPE/v1.4.0: Password Expiration...foi correspondida, assim como o assunto pw-expiration/LPE/v1.3.1: Password Expiration...e pw-expiration/LPE/v1.2.0: Password Expiration....

Observação: o Outlook abriu o menu suspenso de pesquisa quando ativei a ferramenta de recorte, mas quando os resultados da pesquisa foram exibidos, a lista suspensa foi recolhida (adicionei marcações amarelas na ferramenta de recorte para ilustração).

Por exemplo, esta é uma linha de assunto literal de uma mensagem correspondente (alemão):

Subject: pw-expiration/LPE/v1.4.0: Passwortablauf von testuser vor 4.456
 Tagen

No entanto, quando digitei "v1.4"como sequência de pesquisa, "v1.4"ele foi destacado nos resultados da pesquisa, mas ainda assim outras linhas de assunto foram listadas onde a sequência não ocorreu.

Quando entrei "v.1.1", nenhum resultado foi encontrado (o que está correto).

Então o que está acontecendo? Outro produto completamente quebrado do líder de mercado?

Estou sofrendo de um Windows 11 que não inicializa após converter a instalação para IRST ( Intel® Rapid Storage Technology ) / VMD ( Intel® Volume Management Device ) RAID1 via backup/restauração (usando a versão de teste do Acronis True Image ). Antes eu tinha instalado o driver VMD no Windows, mas parece que ele não foi adicionado aos drivers de inicialização (provavelmente porque foi considerado desnecessário naquele momento).

Encontrei um artigo ( Adicionar e remover pacotes de driver a uma imagem offline do Windows ) descrevendo como "injetar" um driver ausente em um WIM a partir de uma mídia de inicialização WinPE e consegui adicionar o driver VMD ausente ao WIM de recuperação.

No entanto, não consegui encontrar um WIM correspondente para a inicialização padrão do Windows (o artigo Instalar um driver de inicialização descreve uma reinstalação (é isso que quero evitar)).

Eu também tentei a versão de teste do Acronis Universal Restore 2025 mais recente (que deve ser capaz de corrigir esse tipo de problema), mas parece que essa versão tem um bug importante: tudo o que eu tentei, não funcionou (problema de suporte pendente) .

Como ainda tinha algum espaço não utilizado no RAID, instalei uma cópia adicional do Windows (esperando que um gerenciador de inicialização do Windows novo e correto pudesse resolver o problema, mas isso não aconteceu).

Agora eu tenho um carregador de inicialização UEFI funcionando que mostra três instalações do Windows 11 (duas que não inicializam e a recém-instalada que não possui muitos outros drivers, mas é capaz de inicializar) para selecionar (eu chamo isso (A partição do gerenciador de inicialização do Windows) o "primeiro" estágio de inicialização, porque quando eu seleciono meu Windows antigo, ele não inicializa (eu chamo isso de "segundo" estágio de inicialização, obviamente acontecendo antes que o "Windows" possa acessar os drivers realmente instalados ).

Então minhas perguntas são:

• Descreva como o segundo estágio da inicialização do Windows carrega os drivers necessários
• Se um driver estiver faltando na etapa acima, posso (e em caso afirmativo: como?) adicioná-lo para que o Windows inicialize?

Tentando evitar possíveis erros gostaria de definir e utilizar variáveis ​​a serem utilizadas dentro do systemdpróprio arquivo da unidade, ou seja: não para o comando executado.

Por exemplo, considere esta unidade (inválida):

[Unit]
CONFIG=/etc/some_dir/%i.conf
AssertPathExists=$CONFIG
#...

[Service]
EnvironmentFile=$CONFIG
# ...

Então, quero definir variável CONFIGe usá-la para várias diretivas de unidade. Isso é possível?

Para corrigir um sistema SLES15 não inicializável, inicializei a imagem do Rescue, montei o sistema existente em /mnt, e depois fiz chroot /mnt(estou deixando de fora os detalhes, pois provavelmente são conhecidos (ou encontrados em Como você cria um ambiente chroot para OpenSUSE Leap ? )).

Ao tentar reconstruir o initrd usando dracutexiste o problema de que o kernel que está sendo usado no sistema de resgate não corresponde ao kernel encontrado no chrootambiente.

Por exemplo, a saída é:

dracut: cannot find module directory /lib/modules/5.3.18.57-default

( 5.3.18.57-defaulté o kernel do sistema de recuperação; o kernel que não inicializa é 5.3.18-150300.59.46-defaultpor exemplo)

Não tenho certeza de qual será a sintaxe correta; eu tenho que especificar o caminho completo para o initrd e o kernel e, em caso afirmativo, a variante "vmlinuz" ou a variante "vmlinux.gz"?

Acabei de descobrir um problema que não entendo (SLES15 SP2):

Eu tinha configurado incorretamente um logrotateserviço (em /etc/logrotate.d). No SLES 15 logrotate.serviceé acionado logrotate.timerdiariamente.

No entanto, meu serviço mal configurado parece registrar uma mensagem de erro apenas uma vez (que foi a principal razão pela qual não descobri o problema por um longo tempo).

Alguém pode explicar o que está acontecendo? Outros serviços logrotate parecem ser executados (não tenho certeza).

Alguns detalhes

O erro de logrotate foi causado por uma postrotateação com falha, especificamente a falha ao enviar SIGHUPpara o processo em execução.

Mensagens do Syslog:

Dec 18 00:00:20 h16 systemd[1]: Starting Rotate log files...
Dec 18 00:00:20 h16 logrotate[41799]: Failed to kill unit \x7b__SERVICE__\x7d.service: Unit \x7b__SERVICE__\x7d.service is not loaded.
Dec 18 00:00:20 h16 logrotate[41799]: error: error running shared postrotate script for '/var/log/iotwatch/MD10/*.log '
Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Dec 18 00:00:20 h16 systemd[1]: Failed to start Rotate log files.
Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Unit entered failed state.
Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Failed with result 'exit-code'.

Tentando construir meu próprio pacote monit RPM no SLES12 SP5 usando rpmbuild, recebi um erro que me confunde:

> rpmbuild -ba -r ~/rpmbuild GNU/RPM/monit.spec
error: Failed build dependencies:
        flex >= 2.6 is needed by monit-12:5.29.0-0.0.x86_64
        bison >= 2.7 is needed by monit-12:5.29.0-0.0.x86_64
        libopenssl-devel >= 1.0.2p is needed by monit-12:5.29.0-0.0.x86_64
        pam-devel >= 1.1.8 is needed by monit-12:5.29.0-0.0.x86_64
> rpm -q flex bison libopenssl-devel pam-devel
flex-2.6.4-9.7.1.x86_64
bison-2.7-6.107.x86_64
libopenssl-devel-1.0.2p-1.13.noarch
pam-devel-1.1.8-24.49.1.x86_64

Parece que todas as dependências estão lá, mas ainda rpmbuildreclama!

Não vejo o óbvio, ou há algo quebrado rpmbuild? O pacote que fornece rpmbuildé rpm-build-4.11.2-16.21.1.x86_64(mais recente até hoje).

Informação adicional

Parece que tem algo quebrado no rpmbuild, pois ao adicionar --nodepsa compilação dá certo, mas notei que o "buildroot" especificado está duplicado, ou seja: ele usa "~/rpmbuild/~/rpmbuild/BUILDROOT" ao empacotar, mas o "BUILD" correto diretório ao compilar.

Eu estou querendo saber como detectar o modo promíscuo de uma interface no Linux moderno ("Modern" significando a falta de netstat).

Estou procurando uma solução mais amigável do que verificar o sinalizador 0x100no /sys/class/net/*/flags.

A história completa pode ser encontrada no openSUSE Bugzilla , mas aqui está o resumo:

Para o openSUSE Leap 15.3, as "teclas de função especiais" (teclas de mídia, etc.) não funcionam ou não funcionam de forma confiável para um Lenovo Thinkpad E15 (2ª geração).

Eu gostaria de usar as teclas especiais e, mais especificamente, o recurso para suspender/retomar o laptop sem precisar desligar/desligar e reiniciar/ligar.

Eu não entendo (com base em https://ubuntuforums.org/showthread.php?t=1643334 ):

% grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sde  ### does not match
% echo -e 'LUKS\xba\xbe...' | grep -a -b -P --only-matching 'LUKS' ### matches
0:LUKS
% echo -e 'LUKS\xba\xbe...' | grep -z -a -b -P --only-matching 'LUKS' ### matches
0:LUKS
% echo -e 'LUKS\xba\xbe...' | grep -z -a -b -P --only-matching 'LUKS\xba' ### does not match
% echo -e 'LUKS\xba\xbe...' | grep -z -a -b -P --only-matching 'LUKS\xba\xbe' ### does not match

Por que o grep não corresponde (como obviamente deveria) e o que tenho que fazer para que corresponda?

Eu tentei esses comandos no Tails 4.18 e no openSUSE Leap 15.2.

Semelhante, mas não idêntico a Executar script no desligamento/reinicialização com systemd :

Eu quero executar um processo personalizado usando systemdquando o sistema está sendo desligado (desligamento ou reinicialização, talvez pânico também) e quando o sistema está inicializando. Ambas as ações devem ser executadas o mais cedo possível.

Obviamente o Typeserviço será um oneshot, mas não tenho certeza sobre o resto ( Wants, Before, After, WantedBy, etc.).

Como meu processo precisa do diário, acrescentei (entre outros):

[Unit]
DefaultDependencies=no
Wants=syslog.target
After=local-fs.target exit.target
Before=multi-user-target

[Service]
Type=oneshot
RemainAfterExit=no

[Install]
WantedBy=multi-user.target

Ao habilitar o serviço, meu programa é iniciado (via ExecStart=) após a montagem dos sistemas de arquivos locais, mas é reiniciado imediatamente (via ExecStop=) antes que os arquivos temporários sejam criados. Na reinicialização, ele não foi iniciado.

Adaptando uma visualização SNMP para o net-snmp 5.7.3, não consigo excluir IF-MIB::ifPhysAddressda minha visualização: o que eu tentei, ainda recebo os endereços MAC em arquivos snmpwalk. Ainda assim, tenho certeza de que minha visão está sendo usada, pois outras exclusões funcionam .

Então aqui vai minha última tentativa:

view publ included .iso.org.dod.internet.mgmt.mib-2 fc
# iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1)

view publ excluded .1.3.6.1.2.1.2.ifTable.ifEntry.ifPhysAddress ff:c0
# 1 3 6 1 2 1 interfaces(2) ifTable(2) ifEntry(1) ifPhysAddress(6)
# .1.3.6.1.2.1.2.2.1.6

# this works:
view publ excluded .1.3.6.1.2.1.ip fe
# ip(4)

Atualização (2021-01-08)

O OID e a máscara fornecidos inicialmente estavam errados, causando erro bad SUBTREE object id. Ainda assim, mesmo com o OID e a máscara fixos, as ifPhysAddressentradas ainda são incluídas na visualização.

Atualização (27/01/2021)

Descobri que usar os nomes simbólicos causa o problema: se eu usar apenas IDs numéricos, funciona.

Ainda assim, não sei o que causa o problema: O IF-MIB.txtestá localizado em /usr/share/snmp/mibs, contém as definições que estão sendo usadas e está incluído no arquivo net-snmp-config --default-mibdirs.

Esta sintaxe é aceita, mas a coluna da tabela não é excluída:

view publ excluded IF-MIB::ifPhysAddress ff:c0

Usando o Windows 10, tive que alterar meu usuário por um que usa o Active Directory (AD), o que significa que obtive um novo SID e %userprofile%caminho. Depois de copiar e ajustar todos os arquivos, configurações e algumas ACLs, tenho um problema que o LibreOffice Writer reclama por não conseguir bloquear um arquivo (como " arquivo está bloqueado para edição por usuário desconhecido "), sugerindo abri-lo somente leitura, ou para abrir uma cópia do arquivo. Quando tento editar uma cópia, o Writer reclama " Erro de gravação. Não foi possível gravar o arquivo ".

Não tenho ideia de onde poderia estar o problema (os detalhes do erro são muito ruins), então já verifiquei:

• Diretório e arquivo de propriedade do SID atual com acesso total
• Posso criar uma cópia do arquivo em questão no mesmo diretório
• Outros arquivos têm o mesmo problema

O que mais eu poderia verificar?

Semelhante a Como você adiciona uma rota de buraco negro em sua rede? , mas gostaria de saber como tornar essa rota permanente no SLES 12.

No YaST, só posso adicionar rotas "normais".

Eu tenho um computador openSUSE que começou com o BtrFS cedo (como o Leap 42.2). Em um momento no passado, o subvolume /tmp ficou cheio (um arquivo grande) e não consegui recuperar espaço até a reinicialização ( rmacionou um No space left on device). Então tudo parecia bom por pelo menos um ano.

Mas recentemente (no Leap 15.1 nesse meio tempo) o BtrFS ficou cheio novamente, e eu me perguntei o que fazer: eu tive muitos instantâneos como este:

# ls -l /.snapshots/
total 4
drwxr-xr-x 1 root root  32 Dec 18  2015 1
drwxr-xr-x 1 root root  32 May 14 09:45 1820
drwxr-xr-x 1 root root  66 May 14 09:46 1821

...

drwxr-xr-x 1 root root  32 Aug  8 08:08 1926
drwxr-xr-x 1 root root  38 Aug  8 08:09 1927
drwxr-xr-x 1 root root  38 Aug  8 08:12 1928

Depois de ter verificado todas as somas de verificação dos blocos com sucesso (sem problemas), iniciei um "saldo" esperando que algum espaço livre aparecesse. Mas o equilíbrio nunca parecia terminar, então tentei abortá-lo. Depois de esperar pelo menos 15 minutos para o balance abortar, reiniciei o computador para tentar outra coisa. Naquela época, o sistema de arquivos estava 99% cheio.

Pensei em limpar o instantâneo mais antigo ( 1) usando rm -rf /.snapshots/1. Infelizmente, depois de terminar, os programas essenciais /usrdesapareceram e meu sistema não inicializou!

Então, minha pergunta é: esse é o comportamento esperado ou fiz algo errado? Se fiz algo errado, qual é o procedimento correto para remover instantâneos antigos?

Escrevi uma unidade de serviço systemd que permite a criação de várias instâncias. Um script wrapper lê detalhes de configuração para a instância de um arquivo de configuração comum, criando o comando real a ser executado. Até agora isso funciona (start, stop, status).

No entanto, quando especifico uma instância que não pôde ser encontrada (chamada "instância falsa") no arquivo de configuração, meu ExecStartcomando falha (conforme pretendido). Nenhum comando além do script wrapper (que termina, é claro) é iniciado.

Infelizmente, o systemd enlouquece: ele tenta repetidamente reiniciar a "instância falsa". Cada statuscomando relata um erro e também não consigo acessar stopessa instância falsa. Portanto, mesmo que nada esteja em execução, o systemd tem algum conhecimento sobre essa "instância falsa". Como posso remover isso?

Existe um código de saída especial que faz o systemd esquecer a instância imediatamente? (eu poderia tentar RestartPreventExitStatus=nesse meio tempo)

Eu tenho um arquivo de serviço systemd usando instâncias que funciona bem para starte status, mas depois stopde um subsequente statusexibe estas mensagens de erro:

Runtime directory is not valid, ignoring assignment: /var/run/iotwatch/%i
Unknown lvalue 'PidFile' in section 'Service'

Aqui estão os detalhes: Primeiro, o arquivo de serviço /usr/lib/systemd/system/[email protected]:

[Unit]
Description=iotwatch I/O performance monitor instance %I
Documentation=man:iotwatch(1)
PartOf=iotwatch.target
#Requisite=
After=nss-user-lookup.target time-sync.target paths.target
#Before=

[Service]
Type=forking
Environment="IOTWATCH_INSTANCE=%i"
RuntimeDirectory=/var/run/iotwatch/%i
WorkingDirectory=/var/run/iotwatch/%i
ExecStart=/usr/lib/iotwatch/iotwatch-service-wrapper %i start
#ExecReload=/usr/...
ExecStop=/usr/lib/iotwatch/iotwatch-service-wrapper %i stop
#SyslogIdentifier=%p-%i
TimeoutStopSec=30
PidFile=/var/run/iotwatch/iotwatch-%i.pid
Restart=always
RestartPreventExitStatus=5 6
StartLimitBurst=1

[Install]
WantedBy=multi-user.target

Em seguida, o status após o início:

h02:~ # systemctl start iotwatch@VAR -l
h02:~ # systemctl status iotwatch@VAR -l
● [email protected] - iotwatch I/O performance monitor instance VAR
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-04-25 11:40:47 CEST; 6s ago
     Docs: man:iotwatch(1)
  Process: 12907 ExecStart=/usr/lib/iotwatch/iotwatch-service-wrapper %i start (code=exited, status=0/SUCCESS)
 Main PID: 12920 (iotwatch-VAR)
    Tasks: 4 (limit: 512)
   CGroup: /system.slice/system-iotwatch.slice/[email protected]
           └─12920 ./iotwatch-VAR -l /var/log/iotwatch/VAR/iotwatch-VAR.log -m I -p /var/run/iotwatch/VAR/iotwatch-VAR.pid -d1 -a0.00 -b512 -i4 -sD -t0.5 -TX=0.25:0.50,A=0.025:0.05 -OR -OS:T=F75,S:M=O52,N:3.29/60,Q:C=120,P:nagios.nagios=0664 /dev/sys/var

Apr 25 11:40:47 h02 systemd[1]: Starting iotwatch I/O performance monitor instance VAR...
Apr 25 11:40:47 h02 iotwatch-service-wrapper[12907]: Starting iotwatch VAR
Apr 25 11:40:47 h02 systemd[1]: Started iotwatch I/O performance monitor instance VAR.
h02:~ # ll /var/run/iotwatch/VAR/iotwatch-VAR.pid
-rw-r--r-- 1 root root 6 Apr 25 11:40 /var/run/iotwatch/VAR/iotwatch-VAR.pid

E, finalmente, o status após a parada:

h02:~ # systemctl stop iotwatch@VAR -l
h02:~ # systemctl status iotwatch@VAR -l
● [email protected] - iotwatch I/O performance monitor instance VAR
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:iotwatch(1)

Apr 25 11:40:47 h02 systemd[1]: Started iotwatch I/O performance monitor instance VAR.
Apr 25 11:41:24 h02 systemd[1]: Stopping iotwatch I/O performance monitor instance VAR...
Apr 25 11:41:24 h02 iotwatch-service-wrapper[12962]: Stopping iotwatch VAR
Apr 25 11:41:27 h02 systemd[1]: Stopped iotwatch I/O performance monitor instance VAR.
Apr 25 11:41:27 h02 systemd[1]: [/usr/lib/systemd/system/[email protected]:12] Runtime directory is not valid, ignoring assignment: /var/run/iotwatch/%i
Apr 25 11:41:27 h02 systemd[1]: [/usr/lib/systemd/system/[email protected]:19] Unknown lvalue 'PidFile' in section 'Service'
Apr 25 11:41:27 h02 systemd[1]: [/usr/lib/systemd/system/[email protected]:12] Runtime directory is not valid, ignoring assignment: /var/run/iotwatch/%i
Apr 25 11:41:27 h02 systemd[1]: [/usr/lib/systemd/system/[email protected]:19] Unknown lvalue 'PidFile' in section 'Service'
Apr 25 11:41:32 h02 systemd[1]: [/usr/lib/systemd/system/[email protected]:12] Runtime directory is not valid, ignoring assignment: /var/run/iotwatch/%i
Apr 25 11:41:32 h02 systemd[1]: [/usr/lib/systemd/system/[email protected]:19] Unknown lvalue 'PidFile' in section 'Service'

Como posso corrigir o arquivo de serviço para evitar essas mensagens?

Como estou meio confuso sobre qual é a ideia por trás systemdde 's systeme userunidades ou serviços, gostaria de pedir uma explicação.

Especificamente, pensei que as unidades de sistema são para unidades que fazem parte do sistema operacional do fornecedor, enquanto as unidades de usuário são para complementos locais do cliente.

Mas parece que as unidades do usuário são tratadas de maneira diferente systemd(por exemplo systemctl daemon-reload, não afeta nenhuma unidade do usuário, enquanto a página do manual afirma: " Recarregue a configuração do gerenciador do systemd. Isso executará novamente todos os geradores (consulte systemd.generator(7)), recarregue todos os arquivos da unidade , e recrie toda a árvore de dependências. "), portanto, não é apenas uma estrutura organizacional, mas uma estrutura verdadeiramente semântica.

Eu portei meu daemon controlado por LSB para systemd usando um script wrapper que inicia e para o daemon. Meu arquivo de serviço systemd (multi-instância) usa Type=forking, ExecStart=..., ExecStop=...e PIDFile=....

Ao iniciar, tudo parece OK no systemd, mas parar sempre parece falhar. Como no ambiente LSB isso funcionou bem, suspeitei que o systemd (228) fizesse algo ruim.

Na verdade, descobri que, após uma inicialização bem-sucedida , o arquivo PID desapareceu , então meu script wrapper retorna com o código de saída 1 (já que o arquivo PID não foi encontrado onde esperado).

Então, o systemd realmente remove o arquivo PID? O efeito colateral é que o systemd parece matar meu daemon com força depois que o script wrapper retornou um erro.