Талян

stripos и strpos работают правильно

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

Чтобы значения отправлялись, нужно полям формы (input, select, textarea и т.д.) обязательно указывать атрибут name

<select name="opt">

ОП, ты хочешь странного. Осознай, что демоны (а systemd управляет как раз программами типа daemon) по определению не предназначены для взаимодействия непосредственно с пользователем, в частности через терминал. А значит, у тебя два выхода:

1. Перестать хотеть странного, и реализовать нормальные логи и анализировать их. Тогда можно будет в любой момент посмотреть историю, выведенную в лог.
При необходимости отслеживать файл лога в реальном времени можно использовать команду tail -f файл.log. Почитай про неё.
Также можно натравить на лог какую-нибудь утилиту мониторинга, которая будет его читать и посылать тебе оповещения о событиях по другому каналу.
Если лог большой, есть logrotate.
Минус - специфические терминальные фишки в логе работать не будут. Скажем, прогрессбар там не сделаешь, и ввести текст не получится.

2. Отказаться от запуска программы как классического демона, и запускать её через утилиту screen. Тогда ты сможешь сконнектиться к сессии screen когда угодно.
Плюс - взаимодействие с терминалом как обычно. В том числе из разных ssh сессий.
Минус - screen не самая удобная штука, сочетания клавиш там мозголомные. Плюс всё равно запуск screen придётся заворачивать в systemd если тебе нужен автозапуск и автоперезапуск.

почему моя настройка неправильна и не соответствует тз ?

Потому что в первом правиле вы разрешаете NEW, независимо от портов, так что второе и третье правила становятся бесполезны, и без них уже открыты все порты. Уберите NEW в первом правиле.

а также позволял устанавливать исходящие соединения

А в последнем правиле лучше бы вообще убрать -m conntrack --ctstate NEW,ESTABLISHED,RELATED.

Сервер
Факт в том, что для синхронизации блокчейна Bitcoin нужно больше ресурсов. Чем больше ресурсов, тем быстрее блокчейн засинкается. Если будет мало, может никогда не засинкаться, поскольку демон будет тупо прибиваться OOM Killer'ом. Поэтому, если есть возможность менять характеристики VPS, лучше сделать на первые несколько дней, сервак помощнее, как блокчейн засинкается - уменьшить ресурсы.
Характеристики на которых блокчейн будет активно синкаться - 4 ядра CPU и 16 GB памяти
Характеристики на которых работает засинканный блокчейн - 2 ядра CPU и 8 GB памяти

Можете воспользоваться этими цифрами. Думаю их можно изменить касательно памяти в меньшую сторону, но придется следить за статусом синхронизации. Мной были выбраны именно эти, поскольку такая градация серверов в AWS. Если интересно, это t3a.xlarge и t3a.large соответсвенно. Менее 4 гиг памяти делать не советую, да и на 4х гигах не факт, что будет работать.

На таком сервере с SSD диском блокчейн синкается примерно за неделю.

Диск
Не уверен, что хватит скорости обычного сетевого хранилища. Я сам не проверял, сейчас тестируем подобное решение на работоспособность, поскольку такое хранилище дешевле. В моем случае это требуется больше для безопасности, а вам бы посоветовал пойти другим путем.
Размер Bitcoin блокчейна около 450 гиг (лень искать точнее, 420 был год назад), плюс 50% на рост и запас, следовательно диск надо выделять 1 ТБ. Т.е. террабайт никому не нужных данных.
У самого Bitcoin и почти всех его форков есть опция prune, которой можно ограничить размер хранилища блоков. Тут можно найти описание параметра. Опытным путем было найдено оптимальное значение этого параметра в 2,5 ГБ. Больше можно, меньше нет. Не помню подробностей, но не все блокчейны умеют меньшие значения и начинают вести себя странно, косячить те есть. Т.е. в конфиге добавляете строку prune=2500 и демон начнет автоматически удалять старые блоки, держа размер блокчейна на диске около 2,5 гиг. При этом сам блокчейн будет в засинканном состоянии.

Ну и зачем, собственно, это все про диски. Воспользовавшись обрезкой вы можете не городить сетевое хранилище, а просто хранить блокчейн на SSD

Похоже на то, что hare run не нравятся виндовые концы строк (CR/LF). Можно использовать утилиту dos2unix для приведения концов строк в понятный hare вид (LF).

Решение заключается в настройке порта коммутатора хуавей в режим hybrid, который будет подключаться на порт маршрутизатора с подинтерфейсами.
И настроить на пропуск тегированных пакетов командой port hybrid tagged vlan 1 273
после этого маршрутизация между вланом (native) 1 и vlan 273 заработала)

button {
  height: 64px;
  width: 256px;
  border-top-left-radius: 5px 50%;
  border-top-right-radius: 5px 50%;
  border-bottom-left-radius: 5px 50%;
  border-bottom-right-radius: 5px 50%;
  border: none;
}

Ничто не мешает таймстампу быть отрицательным.

$t1 = (new DateTimeImmutable('1900-01-01T00:00:00'))->getTimestamp();
$t2 = (new DateTimeImmutable('1950-01-01T00:00:00'))->getTimestamp();
$t = rand($t1, $t2);
print (new DateTimeImmutable())->setTimestamp($t)->format(DateTimeInterface::RFC3339);
// 1915-10-14T19:08:14+00:00

в фаерволе разрешение пропишите, на сервере. хотя если по локалке открывается...

точно проброс правильно сделали и на нужный адрес?

И точно у Вас внешний IP от провайдера есть?
и проверяете Вы с другого интернета? или из своего же вифи?

Допустим так:

move_files.sh

#!/usr/bin/env bash

find some_dir_with_css_and_jpg_files/ -name "*.jpg" -print0 | xargs -0 -I {} mv {} dir_1/

Дальше под себя допили по аналогии.

используйте
https://github.com/iksaku/laravel-mass-update - под капотом CASE/WHEN/THEN

сырым sql такое можно сделать через CASE/WHEN/THEN

UPDATE table
SET column2 = (CASE column1 WHEN 1 THEN 'val1'
                 WHEN 2 THEN 'val2'
                 WHEN 3 THEN 'val3'
         END)
WHERE column1 IN(1, 2 ,3);

или как работает UPSERT в laravel

INSERT into `table` (id, fruit)
    VALUES (1, 'apple'), (2, 'orange'), (3, 'peach')
    ON DUPLICATE KEY UPDATE fruit = VALUES(fruit);

в postgress вместо `ON DUPLICATE KEY UPDATE` будет `ON CONFLICT (xxx) DO UPDATE `