С файлами всё всегда было просто:
|
1 |
find /var/path/ -type f -mtime +10 -delete |
И все, находит все файлы по указанному пути, которые старше 10 дней и удаляет их. Но если такое попробовать сделать с директориями — получим ошибку «directory not empty». Но выход есть, можно использовать xargs
ВПН, как много теперь значат для всех эти три буквы. Еще пару месяцев назад он нужен был для работы на удаленке. А чуть больше года назад о нем знали вообще лишь единицы.
Некоторое время назад я проводил собеседования, подбирая себе замену в ИТ отдел. Некоторым кандидатам задавал вопрос сам — какой ВПН они бы использовали для объединения регионально распределенной сети, некоторые кандидаты сами задавали вопросы в момент моего рассказа как и что было устроено на тот момент в компании. Два кандидата, которые прошли собеседования в разные временные промежутки и с которыми мне удалось пообщаться уже более подробно в момент передачи дел, рассказывали мне о том, как небезопасен протокол PPTP для создания VPN туннеля. О том, что он был скомпрометирован и об этом даже сам Microsoft писал... На мой вопрос, видели ли они хоть раз своими глазами взломанный туннель, перехваченные пакеты и саму словарную атаку — ни один не смог ответить утвердительно. Однако спорить я не собирался и каждый остался при своем. Мой преемник перевел всё на OpenVPN и потерял достаточно в скорости работы, а я порой всё еще использую старый добрый PPTP.
А веду я к тому, что можно и нужно использовать разные реализации в зависимости от задач, а не просто по стандарту «так быть должно» или «так не должно быть». Понятно, что если речь идет о финансовом секторе, или еще более серьезных направлениях — там не возникнет даже вопроса какие протоколы использовать. Но если речь о решении конкретной бизнес задачи — то тут не место однозначному «не по стандарту». Я до сих пор уверен, что если стоит задача сломать конкретную инфраструктуру — её сломают, и не обязательно из-за незащищенного VPN. Ну да ладно, хватит лирики.
|
1 2 |
export JAVA_HOME=/usr/lib/jvm/jdk-18/ export PATH=$PATH:$JAVA_HOME/bin |
Открываем новый терминал и проверяем — java --version
|
1 2 3 |
java 18 2022-03-22 Java(TM) SE Runtime Environment (build 18+36-2087) Java HotSpot(TM) 64-Bit Server VM (build 18+36-2087, mixed mode, sharing) |
Встала задача перенести gitlab на новый сервер. Описаний как делать бекап и как его восстанавливать в сети достаточно. Официальная документация тоже достаточно полная. Но я словил один баг, который не описан. Спешу поделиться. Жаль, если Вы прочтете его и будет уже поздно. Главное сохранять оригинальные файлы конфигурации...
Итак.
Даже когда на сервер запрещено логиниться ото всюду, кроме разрешенных ip адресов — все равно может потребоваться мониторить удачные (да и неудачные вдруг) входы на сервер. В принципе даже в шаблоне по умолчанию для Linux серверов есть элемент количества залогиненых пользователей, и можно просто повесить триггер на изменение этого числа. Но мне нужно было получить ip адрес, с которого произошел вход. Вот как я это сделал.
Свежие комментарии