Saboteur

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

1. В настройках фтп сервера, если он запущен под рутом, может быть опция для смены владельца файлов.

2. В аплоад директорию можно установить SGID бит, тогда все новые файлы будут аплоадиться с правами владельца директории - то есть ставишь SGID на директорию и меняешь владельца на юзера, от имени которого ходишь по фтп.

3. В настройках ftp сервера или его процесса, устанавшиваешь umask на 0.

if [ "$projectDir" = "video" -o "$projectDir" = "audio" ] && [ "$flag" != "noflag" ]; then

Внутри оператора [] нельзя использовать &&, потому что это не синтаксис [] а синтаксис внешнего баш.
Правильно так

[ "$projectDir" == "video" -a "$flag" != "noflag" ]

или

[ "$projectDir" == "video" ] && [ "$flag" != "noflag" ]

string='-rw-r--r-- dmitriy/dmitriy 9844 2023-06-16 19:33 acts/actFirst_53632_1102.htm'
year=$( awk '{print substr($4,1,4)}' <<<"$string" )

Что-то у вас пример старого адреса отличается от адреса, который указан как доступ к RDP

Так адрес поменялся или не поменялся?
Старый адрес совпадал с адресом RDP?

У вас в вопросе немного хаотично, и подозреваю что вы сами не знаете что именно поменялось. Это и стоит уточнить - точно ли поменялся айпи адрес, с какого на какой, какое отношение RDP адрес имеет к тому, что поменялся.
Ответы на эти вопросы есть только у вас.

1. Разобраться с тем что такое IP и что такое белый IP.
2. Если у тебя белый IP, то настроить проброс нужного порта на роутере на твой комп
3. Если у тебя серый IP, купить и провайдера белый IP

Почему бы просто не провести тесты?
Не так уж сложно добавить опцию, чтобы это коснулось части пользователей и просто проверить как оно будет работать на разные s3 сервисы.

Все обучение без практики - ничто.
Практика без смысла - демотивирует.

Придумай себе проект и пиши его. Можешь чисто для себя что-то придумать.
Популярно сейчас взять движок телеграм бота и попробовать в боте реализовать интересный и полезный функционал. Постепенно усложняй, дорабатывай.
Добавляй технологии (базы данных, авторизация, интеграция с какими-то апи, с мониторингом).
Гит можно и без команды использовать для своих изменений, чтобы мог откатить что-либо

HTTPS = HTTP + TLS, между клиентом(браузером пользователя) и удаленным сервером(сайтом) строится TLS туннель на основе публичных ключей, далее идет обмен приватных симметричных ключей и затем https сессия шифруется уже симметрично.

При помощи публичного ключа сервера идет шифрование симметричного ключа, который передается клиентом серверу. То есть один публичный ключ, один симметричный ключ.

В HTTPS условно невозможны атаки типа MITM

То есть? MITM зависит не от HTTPS, а от того, доверяете ли вы серверу. Условно тут могут и сертификат украсть и днс подшаманить и вам в доверенные сертификаты подсунуть нужный, что обычно делается в корпорациях (и это можно увидеть).

Обеспечивает ли HTTPS полную невозможность компрометации данных?

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

Возможно прозвучит глупо, но всё же - почему многие люди считают что условные третьи лица могут читать их переписки/видеть какие-либо передаваемые и отправляемые данные/оставлять цифровой след в интернете?

Потому что ломают не только HTTPS, есть множество точек уязвимости.

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

Шифрование не дает анонимности. Ваш IP адрес видит и провайдер и удаленный сервер.

Скажите, правильно ли я понимаю, что провайдер и все промежуточные узлы видят только IP адрес на уровне L3 (и мак на уровне L2), а сами данные L4 на сеансовых и следующих уровнях для них зашифровано и недоступно? (из-за шифрования HTTPS) Т.е. в худшем случае мы можем только засветить свой белый айпишник, который привязан к географическому положению (и также хранится на логах сессий в маршрутизаторе у провайдера), но сами данные никто увидеть не сможет?

Почти так. Но кое-какие данные идут не только по HTTPS. Есть DNS реквесты, есть пару HTTP реквесты которые идут во время рукопожатия HTTPS.

И если это так, то то же замедление ютуба или недавнего Дискорда- DPI (Deep Packet Insepction почему-то именно слово "Deep" настораживает.) - Как система может определять тип пакетов/траффика и исходя из этого делать уже какие-то выводы/принимать действия?

Ну тут банально - куда ты подключаешься - к серверам гугла? Значит тормозим.

Там всё же вводятся ограничения на уровне ip-адреса ресурса или же эти системы умеют копать глубже, на уровне приложений? В таком случае как тогда это стыкуется с безопасностью и шифрованием данных в HTTPS, если DPI может блочить по контенту?

Шифрованный VPN Трафик отличается от шифрованного HTTPS трафика. VPN тоже разными технологиями делается. Трафик условного звонка по телеграмму отличается от HTTPS траффика. То есть можно анализировать тип трафика. Естественно содержимое страничек DPI не видит (если не включает в себя MITM). Незашифрованный траффик DPI может по заголовкам фильтровать очень гибко.

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

В основном потому что корпоративный MITM

Все приложения должны крутиться в контейнерах. Соответственно Jenkins тоже должен жит в контейнере.

Почему?
Если дженкинс должен УПРАВЛЯТЬ контейнерами, то почему он сам должен крутиться внутри контейнера?
Или задача запускать контейнер в контейнере в контейнере?

Дженкинс в контейнере удобен, если вы запускаете его в кубере, чтобы он себе поднимал в нужный момент агенты и останавливал их. Просто так на хосте делать контейнер для дженкинса - ну можно конечно, но зачем..?
Запустить в контейнере мастер? или агент? Или у вас эксекуторы только на мастере?

Если у вас нет оркестратора, то нет смысла пихать дженкинс в контейнер, а потом изнутри искать выход наружу к папкам и ексекуторам. То есть у вас подход какой-то неправильный.

table resources
user_name, user_id, w1_total, w1_used, w2_total, w2_used, w3_total, w3_used, w4_total, w4_used, w5_total, w5_used

table groups
user_id, group_name, w1,w2,w3,w4,w5, current_task

Напиши веб-приложение, которое будет возвращать html/css/js страничку.
Можно даже на хостинге его через php вызывать. Будет кроссплатформенно.

tar -cz /home/target | sshpass -p 'pwd' ssh -p 23 username@server.com 'cat > /home/backups/destination.tar.gz'

Все должно так работать. Если у вас ошибка от tar, то может это не stdout а stderr?
Приведите текст что там не так. Файл в конечно счете правильный выходит?

1. Телеграм поддерживает работу сразу с несколькими аккаунтами, между которыми можно переключаться в два клика.
2. В телеграмме можно сделать общий чат, в котором даже сделать подканалы для разных тем.
3. В телеграмме пользователь может создать группы и добавить в группу каналы или пользователей.
4. Очень удобно зарегать своего бота, которого использовать для различных уведомлений, мониторинг прикрутить к нему например. Можно даже скрипт бота написать для взаимодействия

Но, телеграм может быть рабочим, но не корпоративным мессенджером.
Корпоративный мессенджер должен быть интегрирован с корпоративной почтой, в нем обычным поиском должна быть возможность быстро найти любого сотрудника компании. Поэтому возможно имеет смысл все-таки завести отдельный корпоративный мессенджер, сервер которого хостится on-premise. Маттермост то же.