Есть некое приложение под управлением systemd
Всё работает, всё пишется в journalctl, логи имеют префиксы типа INFO/WARN/ERROR/итд, но для journalctl это всего лишь текст лога, а не метаданные.
Поэтому нельзя фильтровать логи в духе

journalctl -u service -p err

Захотелось приобщиться к модному,молодёжному и поиграться с Wireguard.
Все статьи в гугле сводятся к «я поднял VPN к своему localhost в 1 клик и щястлив, попивая смузи на краю бассейна»
А как рулить подключениями когда у тебя много клиентов помимо localhost?
Если в команде люди постоянно приходят/уходят - надо постоянно пердолить конфиг сервера вручную добавляя/убирая секции Peer?
Научите, пожалуйста, как правильно

Привер лорогугл.
Никак не могу понять, чем обуславливается разное поведение PS4 для разных пользователей, посоветуйте мне ваши советы
Окружение: CentOS 7, bash 4.2.46(2)

Для отладки сложных скриптов использую вот такой сниппет:

export PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

#!/bin/bash
set -x
m=4123
echo start
echo $m
my() {
    echo $1
}

my 123

+(./test.sh:3): m=4123
+(./test.sh:4): echo start
start
+(./test.sh:5): echo 4123
4123
+(./test.sh:10): my 123
+(./test.sh:7): my(): echo 123
123

+ m=4123
+ echo start
start
+ echo 4123
4123
+ my 123
+ echo 123
123

Смотрю серию симпозиумов (о борьбе со злыми духами) на японском, для которых для каждой серии есть аудиодорожка с русским переводом(в отдельной поддиректории)
Есть ли в 2021 году, когда космические корабли бороздят вот это всё, простой способ создать плейлист, чтобы для каждой серии автоматически подключалась аудиодорожка(в единичном случае подключаемая вручную через Аудио->Загрузить из файла)?

Нужно скриптом, на паре-восьмёрке серверов, добавить в конфиг Nginx, после определённого ключевого слова mykeyword, дополнительное описание формата логирования.
Примерный кусок, который нужно вставить

# Additional log_format

log_format myformat escape=json '{'
  '"remote_addr":"$remote_addr",'
  '"status":$status,'
  '"request_time":$request_time,'
  '"http_referer":"$http_referer"'
  '}';

# End of additional log_format

Есть система сбора логов, в которую отдаются логи Nginx в виде JSON.
В log_format используется

"upstream_status":$upstream_status

access_log access.log with_upstream if=$upstream_status

access_log access.log without_upstream if=???

map $upstream_status $need_log {
    "~^$" 1;
}

Как известно, при наличии нескольких апстрим серверов Nginx лепит время ответа от каждого в одно поле примерно так:

$upstream_response_time="upstream1_response_time:upstream2_response_time:...:upstreamN_response_time"

Перехожу на новую Kubuntu путём последовательных апгрейдов, начиная ещё с 1763 года.
И наверняка это неполезно(накапливаются шлаки, токсины, каловые камни), поэтому встал вопрос - как можно сбросить пользовательский профиль минимальными телодвижениями(бэкап $HOME не считается), чтобы я увидел всё глазами первозданного пользователя 20.10

Прадед рассказывал, раньше это делалось удалением ~/.kde, но сейчас старые методы на работают.
Посоветуйте же ваши ответы

Пытаюсь таки немножечко разбалансировать нагрузку(TCP/UDP) на два сервера посредством keepalived, но так как серваков под балансирщик нет, то изучаю вариант совмещения балансировщика и real_server на тех же серваках.
Тестирую на такой конфигурации:
Система: Centos 7, keepalived 2.0.7, один сетевой интерфейс, нагрузка идёт из локальный сети.
Первая нода

! Configuration File for keepalived
global_defs {
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
}

vrrp_instance TEST {
    state MASTER
    interface bond0
    virtual_router_id 51
    priority 150
    advert_int 1
    virtual_ipaddress {
        192.168.1.13
    }
}

virtual_server 192.168.1.13 8010 {
    delay_loop 10
    lvs_sched rr
    lvs_method DR
    persistence_timeout 5
    protocol TCP

    real_server 192.168.1.11 8000 {
       TCP_CHECK {
       }
    }

    real_server 192.168.1.12 8000 {
       TCP_CHECK {
       }
    }

! Configuration File for keepalived
global_defs {
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
}

vrrp_instance TEST {
    state BACKUP
    interface bond0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        192.168.1.13
    }
}

virtual_server 192.168.1.13 8010 {
    delay_loop 10
    lvs_sched rr
    lvs_method DR
    persistence_timeout 5
    protocol TCP

    real_server 192.168.1.11 8000 {
       TCP_CHECK {
       }
    }

    real_server 192.168.1.12 8000 {
       TCP_CHECK {
       }
    }

vel

Долго я оттягивал этот момент, но видимо пришло время написать свой первый systemd unit

Есть старый бинарник, который исторически запускался чуть ли не вручную под выделенным пользователем, в профайле у которого прописаны условные BASE_DIR и LD_LIBRARY_PATH

Хотелось бы иметь для все преимущества systemd, типа автозапуска, унифицированного способа стартом/пуском, рестартом итд

То есть, если его запустить от произвольного пользователя без учёта переменных окружения, то получим нечто вроде:

/path/to/app: error while loading shared libraries: libname.so: cannot open shared object file: No such file or directory

LD_LIBRARY_PATH=/path/to/lib BASE_DIR=/path/to/basedir /path/to/app start

[Unit]
Description=Old app

[Service]
User=appuser
Environment="LD_LIBRARY_PATH=/path/to/lib"
Environment="BASE_DIR=/path/to/basedir"
ExecStart="/path/to/app start"
ExecStop="/path/to/app stop"

[Install]
WantedBy=multi-user.target

Наткнулся на удобную штуку:
Set human-readable link description

ip link set dev ${interface name} alias "${description}"
Examples:
ip link set dev eth0 alias "LAN interface"
Link aliases show up in "ip link show" output, like:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 22:ce:e0:99:63:6f brd ff:ff:ff:ff:ff:ff
    alias LAN interface

mky

Вводные:
есть две сети 1.1.1.0/24 и 2.2.2.0/24
Между ними файрвол, который является шлюзом
Условно примерно так:
1.1.1.0/24-----[(1.1.1.254)FW(2.2.2.254)]-----2.2.2.0/24

Хосты из 1.1.1.0/24 пингуют хосты в 2.2.2.0/24
Хосты из 2.2.2.0/24 пингуют хосты в 1.1.1.0/24
Хосты из 1.1.1.0/24 могут ходить на любые порты в 2.2.2.0/24
Хосты из 2.2.2.0/24 не могут ходить на любые порты в 1.1.1.0/24, потому что люди, отвечающие за связность, из-за недопонимания настроили ACL только в одну сторону. В другую сторону тоже скоро настроят, но связность нужна ещё вчера.
Доступ есть ко всем хостам, доустановка сторонних пакетов затруднена, хотелось бы обойтись максимально стандартными способами.

Задача: как обеспечить связность в обратную сторону(это времянка на день-два, поэтому любые костыли подойдут).

Пока пытаюсь сделать это через SSH туннель.
Идея примерно такая:
1. Выбираем пару произвольных хостов, вешаем на них по новому адресу, чисто под туннель, делаем туннель
1.1.1.123<--->2.2.2.234
На этом шаге хост 2.2.2.234 может подключиться к 1.1.1.123 на любые порты.
2. Хост 1.1.1.123 будет выступать маршрутизатором для остальных хостов в 1.1.1.0/24, поэтому на нём делаем маршрут 2.2.2.0/24 via 1.1.1.123
Хост 2.2.2.234 будет выступать маршрутизатором для остальных хостов в 2.2.2.0/24, поэтому на нём делаем маршрут 1.1.1.0/24 via 2.2.2.234
3.На хостах сети 1.1.1.0/24 делаем маршрут 2.2.2.0/24 via 1.1.1.123
На хостах сети 2.2.2.0/24 делаем маршрут 1.1.1.0/24 via 2.2.2.234

Ожидаемый результат: всё сходу работает через туннель
Актуальный результат: на втором шаге туннель ломается.

Как я понимаю, это случается потому, что пакеты для пиров туннеля тоже заворачиваются в сам туннель, вместо того, чтобы бегать через дефолтный шлюз.

Вопрос: есть ли способ это разрулить? Ну или можно решить это принципиально иначе?

Ping mky, vel, AS, router, anc


Решение:
NETWORK1 - первая сеть, из которой открыты все порты во вторую сеть
REAL_IP_IN_NETWORK1 - изначальный адрес хоста в первой сети
NETWORK1_GATEWAY - дефолтный шлюз на хосте в первой сети
EXT_TUNNEL_IP_IN_NETWORK1 - внешний адрес туннеля на хосте в первой сети
INT_TUNNEL_IP_IN_NETWORK1 - внутренний адрес туннеля на хосте в первой сети

NETWORK2 - вторая сеть, из которой закрыты все порты в первую сеть
REAL_IP_IN_NETWORK2 - изначальный адрес хоста во второй сети
NETWORK2_GATEWAY - дефолтный шлюз на хосте в первой сети
EXT_TUNNEL_IP_IN_NETWORK2 - внешний адрес туннеля на хосте во второй сети
INT_TUNNEL_IP_IN_NETWORK2 - внутренний адрес туннеля на хосте во второй сети

Важное примечание: если убрать вторые адреса и прописывать маршруты между REAL_IP_IN_NETWORK1 и REAL_IP_IN_NETWORK2, то тот хост из второй сети не сможет взаимодействовать с этим (REAL_IP_IN_NETWORK1) хостом из первой сети, так как весь траффик между ними пойдет не по тунелю, а порты перекрыты.

1. На хосте REAL_IP_IN_NETWORK1 вешаем доп. адрес EXT_TUNNEL_IP_IN_NETWORK1 в сети NETWORK1 чтобы туннель строился именно с него:

ip a a EXT_TUNNEL_IP_IN_NETWORK1/32 dev eth0
ip r a EXT_TUNNEL_IP_IN_NETWORK2/32 via NETWORK1_GATEWAY dev eth0 src EXT_TUNNEL_IP_IN_NETWORK1

ip a a EXT_TUNNEL_IP_IN_NETWORK2/32 dev eth0
ip r a EXT_TUNNEL_IP_IN_NETWORK1/32 via NETWORK2_GATEWAY dev eth0 src EXT_TUNNEL_IP_IN_NETWORK2

ssh -b EXT_TUNNEL_IP_IN_NETWORK1 -w 0:0 EXT_TUNNEL_IP_IN_NETWORK2

ip a a INT_TUNNEL_IP_IN_NETWORK1/32 peer INT_TUNNEL_IP_IN_NETWORK2 dev tun0
ip link set dev tun0 up

ip a a INT_TUNNEL_IP_IN_NETWORK2/32 peer INT_TUNNEL_IP_IN_NETWORK1 dev tun0
ip link set dev tun0 up

ip r a NETWORK1 via INT_TUNNEL_IP_IN_NETWORK1 dev tun0 src REAL_IP_IN_NETWORK2

ip r a NETWORK2 via INT_TUNNEL_IP_IN_NETWORK2 dev tun0 src REAL_IP_IN_NETWORK1

ip r a NETWORK1 via REAL_IP_IN_NETWORK2

ip r a NETWORK2 via REAL_IP_IN_NETWORK1

Есть скрипт загружающий файлы на некий сервер и использующий pv в роли шейпера(так как сервер не всегда может переварить поток данных):

for file in files;do pv -L 1000k $file | ncat -w 1 127.0.0.1 1234;done

Вводные
https://www.spirent.com/blogs/positioning/2018/january/gps-rollover-week
GPS-проблема 2019 года или «а нафига нам много разрядов?»

Читаю интернеты и никак не могу понять, будет ли влияние этой проблемы на NTP синхронизацию.
Если предположить, что какой-то stratum-1 сервер pool.ntp.org синхрится от какого-то незапатченного GPS приёмника, то может ли это затронуть мой stratum-3 сервер, который синхрит время в локалке?
Есть ли гарантия, что все ошибки(я имею в виду некорретное время) обработаются выше?

Есть два сервера, один длинный, другой тяжёлый.
На одном есть три контейнера Elasticsearch, для которых настроен проброс портов изнутри на физический адрес сервера, но которые при этом организовались в кластер по своей внутренней сети.
На втором сервере тоже есть один контейнер. И хотелось бы его добавить четвёртой нодой в существующий кластер.
Я не растерялся и прописал три ноды в discovery.zen.ping.unicast.hosts новой ноды.
Но мой план не сработал, судя по логам кластер пытается собраться на внутренних Docker адресах, что не сработает.
Как это разрулить?
Конфиги:
На обоих серверах интерфейс docker0 172.17.0.1/16

docker-compose.yml с первого сервера:

version: '2.2'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.6.0
    container_name: elasticsearch1
    environment:
      - cluster.name=supercluster
      - bootstrap.memory_lock=true
      - discovery.zen.minimum_master_nodes=2
      - "ES_JAVA_OPTS=-Xms32766m -Xmx32766m"
      - "discovery.zen.ping.unicast.hosts=elasticsearch"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata1:/usr/share/elasticsearch/data
    ports:
      - 10.11.12.13:9200:9200
      - 10.11.12.13:9300:9300
    networks:
      - esnet

  elasticsearch2:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.6.0
    container_name: elasticsearch2
    environment:
      - cluster.name=supercluster
      - bootstrap.memory_lock=true
      - discovery.zen.minimum_master_nodes=2
      - "ES_JAVA_OPTS=-Xms32766m -Xmx32766m"
      - "discovery.zen.ping.unicast.hosts=elasticsearch"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata2:/usr/share/elasticsearch/data
    ports:
      - 10.11.12.13:9201:9200
      - 10.11.12.13:9301:9300
    networks:
      - esnet

  elasticsearch3:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.6.0
    container_name: elasticsearch3
    environment:
      - cluster.name=supercluster
      - bootstrap.memory_lock=true
      - discovery.zen.minimum_master_nodes=2
      - "ES_JAVA_OPTS=-Xms32766m -Xmx32766m"
      - "discovery.zen.ping.unicast.hosts=elasticsearch"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata3:/usr/share/elasticsearch/data
    ports:
      - 10.11.12.13:9202:9200
      - 10.11.12.13:9302:9300
    networks:
      - esnet

volumes:
  esdata1:
    driver: local
  esdata2:
    driver: local
  esdata3:
    driver: local


networks:
  esnet:

# curl 'http://10.11.12.13:9200/_cat/nodes'     
172.25.0.3 23 99 52 0.79 1.39 1.62 mdi * 47cooiw
172.25.0.2 43 99 51 0.79 1.39 1.62 mdi - IX8C70Z
172.25.0.4 40 99 51 0.79 1.39 1.62 mdi - tEy_OlF

version: '2.2'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.6.0
    container_name: elasticsearch
    environment:
      - cluster.name=supercluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms8g -Xmx8g"
      - "discovery.zen.ping.unicast.hosts=10.11.12.13:9300,10.11.12.13:9301,10.11.12.13:9302"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata1:/usr/share/elasticsearch/data
    ports:
      - 10.11.12.12:9200:9200
      - 10.11.12.12:9300:9300
    networks:
      - esnet

volumes:
  esdata1:
    driver: local

networks:
  esnet:

Задача: на FTP сервер закачиваются файлы. По триггеру в incron я получаю их имена. Нужно их обрабатывать последовательно, по мере получения. Ситуация, когда предыдущий файл ещё не обработался но уже прилетел один или несколько новых - штатная. Параллельная обработка не вариант, файлы слишком большие, сервер хоть и мощный, может обрабатывать только один файл за раз. Прозреваю нужен способ организации очереди.

Вопрос: что есть из модного молодёжного, чтобы так последовательно обрабатывать файлы? В идеале нужна отказоустойчивость, чтобы очередь не терялась при каких-то нештатных ситуациях.
Смотрел ts/task-spooler ( https://www.ostechnix.com/add-linux-commands-queue-execute-one-one/), заставить это нормально работать сходу не получилось, продолжаю его вяло ковырять.

Была такая конфигурация в /etc/postfix/virtual
account1@mydomain.ru externalservice@domain.com

То есть кто-то шлёт письмо на account1@mydomain.ru, оно пересылается на externalservice@domain.com, где обрабытывается и тот сервис отвечает изначальному отправителю(от имени account1@mydomain.ru)

Со временем появилась необходимость завести второй ящик(так как на такой ранее не работавший адрес шлются письма по ошибке), но чтобы для отправителей всё работало прозрачно как и до этого и ответ был от account1@mydomain.ru.
В лоб я попробовал сделать так:
/etc/postfix/virtual
account1@mydomain.ru externalservice@domain.com
account2@mydomain.ru account1@mydomain.ru

И на вид всё заработало почти как надо, за исключением того, что на externalservice@domain.com письмо приходит с заголовком
Сс: account2@mydomain.ru, и при ответе сервиса конечный пользователь его тоже в итоге видит.

Вопросы:
1) Почему добавляется заголовок Сс. Параметра отвечающего за такое поведение с ходу не нашёл. Удалять его в header_checks тоже не получилось.
2) Есть ли более правильные способы решить эту задачу

Наблюдаю какую-то нелогичное поведение при использовании auth_basic
Мне нужно временно закрыть доступ к главной аутентификацией, при этом всё остальное закрывать не нужно
Конфиг:

   location / {
     auth_basic           "Wassup dawg";
     auth_basic_user_file /home/vasyan/auth/.htpasswd;
     root   /home/vasyan/testapp;
     index  index.html;
     try_files $uri $uri/ /;
   }

   location /api {
     proxy_pass http://someupstream
   }

Окей, лорогугл «Почему Nginx делает редирект да ещё и на внутренний порт»?
Вводные:
nginx.conf

  server {
           listen       1234 ssl;
           server_name  mysweetsupersite.ru;

           location /testapp {
             root   /home/vasyan/apps/;
             index  index.html index.htm;
             try_files $uri $uri/ /;
           }
...

< HTTP/1.1 301 Moved Permanently
< Location: https://mysweetsupersite.ru:1234/testapp/

Логика:
Брать последний кусок URL (после последнего слеша) и подставлять в заголовок апстрим серверу.
Пример:
Запрос http://myserver.ru/action/user/12NZ12984N43490D
Извлекаем 12NZ12984N43490D, подставляем в заголовок.

Есть вот такой кусок конфига.

location ~ ^/action/user/ {
  if ($request_uri ~* "([^\/]+$)" ) {
     set  $user_id  $1;
  }
  proxy_set_header Cookie "USERID=${user_id}";
  ...
  proxy_pass http://backend