как поменять ttl linux
Как навсегда изменить время жизни пакета (TTL) в Ubuntu
В статье о времени жизни пакета был приведён пример изменения TTL в Windows. Сегодня поговорим о том, как поменять значение TTL по умолчанию в Ubuntu-подобных дистрибутивах Linux. Здесь основной нюанс заключается в следующем — поменять значение TTL просто, но нужно его ещё и сохранить.
Для того, чтобы проверить время жизни пакетов в Linux, достаточно также запустить ping localhost. По умолчанию в Linux TTL=64. Для изменения этого значения в Ubuntu и других похожих дистрибутивах используйте команду
Конечно, можно указать и другое значение, кроме 65. На скриншоте ниже видно, что теперь команда ping отображает TTL=65.
Однако настройка TTL сбросится после перезагрузки. Для того, чтобы этого не происходило, нужно добавить данную настройку в автозагрузку. Производится эта настройка из-под пользователя root.
Помните, что постоянно работать под пользователем root нельзя. Используйте его только для настройки системы.
Нам нужно создать файл в каталоге /etc/sysctl.d, я дал ему имя 99_default_ttl.conf, но оно не обязательно должно быть именно таким. Для создания файла я использую удобную мне команду cat (подробнее о командах для создания файлов в Linux можно прочитать по этой ссылке):
После нажатия enter данные со стандартного ввода (т.е. с клавиатуры) будут перенаправлены в файл /etc/sysctl.d/99_default_ttl.conf. Введите нужную нам настройку, а именно:
и нажмите enter. Комбинации Ctrl + D или Ctrl + C запишут изменения в файл. Затем применяем настройки командой
На скриншоте ниже виден весь описанный тут процесс.
Как видите, значение TTL в команде ping также изменилось. И данная настройка сохранится после перезагрузки.
Артём Санников
Языки программирования
Базы данных
Программное обеспечение
Операционные системы
Мобильная разработка
Менеджеры пакетов
Сетевые технологии
CMS системы
Математика
SEO продвижение
Социальные сети
Психология
Хостинг провайдер
Смартфоны
Обход ограничений на раздачу интернета (фиксация TTL) в Ubuntu
Большинство современных операторов мобильной связи, такие как МТС и Yota предоставляют тарифы, которые позволяют пользоваться интернетом без ограничения трафика. Всё вроде бы хорошо, и удобно. Но если рассмотреть этот вопрос более подробно, то всё будет не так уж и хорошо.
Изначально условия тарифа звучат следующим образом: вы можете пользоваться интернетом в любое время суток и без ограничения трафика, но за раздачу интернет-соединения через Wi-Fi, Usb-модем или Bluetooth с вас будет списана абонентская плата в размере N рублей.
P.S: я пользуюсь услугами оператора МТС, и за раздачу интернета раньше снимали 30 рублей в сутки, теперь же снимают по 50 рублей.
Но как быть, если нужно раздать интернет по Wi-Fi, а лишних денежных средств на балансе нет? Всё очень просто! нужно зафиксировать значение TTL файла на определённом значении в операционной системе: Linux, Windows или Mac OS.
P.S.S: данная статья носит исключительно ознакомительный характер, я никого не призываю использовать данную информацию в практических целях.
Изменение значения TTL в операционной системе Ubuntu
Чтобы обойти ограничение на раздачу интернета через телефон на компьютер с Ubuntu на борту, в случае, если ваш оператор Йота, вы должны сделать несколько простых вещей.
2. Вводим следующую команду от супер-пользователя:
4. Сейчас мы должны ввести скрипт с учётом особенности операционной системы вашего смартфона. Если у вас Android или iOS — нужно указать значение TTL=65 (вместо 64), а если Windows — то указываем TTL=129 (вместо 128).
Почему значение на 1 больше? Всё очень просто, значение TTL на компьютере должно быть на 1 больше, чем значение TTL на телефоне, с которого вы раздаете.
Скрипт для обхода ограничений на раздачу интернета для Android и iOS:
Скрипт для обхода ограничений на раздачу интернета для Windows Phone:
5. Для завершения редактирования нажимаем Esc. Затем сохраняем внесённые изменения нажатием клавиш: Shift + ZZ (два раза нажать Z).
6. Присваиваем скрипту права на запуск:
7. Добавляем скрипт в автозапуск:
Всё готово! Мы успешно зафиксировали значение TTL в операционной системе Ubuntu, и обошли ограничение операторов мобильной связи: МТС и Yota, на раздачу интернет соединения по Wi-Fi, Usb-модем b Bluetooth.
Хелп. Помогите окончательно изменить TTL в Linux Mint 19
Более чем уверен, что многие обозревают сайт из операционных систем LInux.
Будучи не слишком опытным пользователем, пытаюсь делать то же самое.
Но в процессе сталкиваюсь с такой проблемой: для того чтобы получить тырнет от жадной йоты методом раздачи с телефона столкнулся с необходимостью изменить TTL компутера на значение 65 вместо 128. Дело само по себе нехитрое и решается простой командой из терминала:
все работает. все хорошо, НО только до перезагрузки, после чего возвращается значение 128 и йота снова начинает хотеть денег.
Перелопатил кучу инструкций, как сделать скрипт, но либо инструкции написаны криво с ошибками в командах, либо я что-то делаю не так. Значение после скриптов становится 64, а не 65, как того хотелось бы((((
Не в деньгах дело. все равно щас оплачу проводной тырнет. Дело принципа. очень хочется знать, где именно рылась собака.
ПыСы: изменить TTL на телефоне на значение 63 не вариант, так как йота этот фокус знает и на мой оппо ф7 получение рута человеческим способом не предусмотрено.
Уря. Все решилось. Вот последовательность команд:
echo «net.ipv4.ip_default_ttl=65» >> /etc/sysctl.conf
ОГРОМНОЕ СПАСИБО ЭТОМУ ДОБРОМУ ЧЕЛОВЕКУ:
GNU/Linux
708 постов 13.2K подписчика
Правила сообщества
Все дистрибутивы хороши.
это повысит до рута
это добавит настройку в файл
echo «net.ipv4.ip_default_ttl=65» >> /etc/sysctl.conf
это применит параметры
после перегрузки будет 65
Введи после изменения правила sudo service iptables-persistent save, и оно сохранится
2021 год, всё работает до сих пор :3
Автор пасяба за вопрос
Раздача с ведроида?
в скрипты стартовые вставить можно.
Shodan.io | Как спастись, куда бежать начинающему разработчику/сис.админу?
Сей материал будет полезен новичкам в вопросе настройки своих серверов и сетевой безопасности. Прошу разбирающихся не бить ссанными тряпками, пост писался из благих побуждений и в некоторых вопросах я могу быть не совсем корректен.
Кратко о shodan. Это поисковый сервис который рандомным образом генерирует IP адресы и проверяет что по ним расположено, в следствии неправильной настройки сервера некоторые данные могут утечь (shodan не щадит никого) либо к серверу может быть получен несанкционированный доступ. К примеру, есть такой пакет для linux совместимых систем как ProFTPD (FTP сервер, что логично) и в нём есть (был?) эксплоит (CVE-2019-12815) позволяющий выполнять код и доставать «секретную» информацию БЕЗ авторизации. Актуально для версии пакета 1.3.5b.
Патч на гитхаб: https://github.com/lcartey/proftpd-cve-2019-12815
Чем опасен этот эксплоит помимо очевидного «выполнять код»? Да всё очень просто, если у вас к серверу привязан домен и не стоит патч на proftpd, то последний любезно предоставит информацию о нём.
Опасно это в первую очередь для тех у кого не самые мощные сервера и нет защиты от DDoS атак. Рекомендую установить патч либо использовать SFTP чтобы не спалить данные о домене. Если ваш IP таки был связан доменом (раскрыт), вам стоит обратиться к провайдеру для его смены, т.к он является скомпрометированным, исправить сие невозможно.
Если вы используете услуги аренды VDS серверов, крайне не рекомендую вообще указывать реальный домен при начале аренды (актуально как минимум для firstvds).
Также крайне не рекомендую при наличии домена, разрешать доступ к серверу через IP.
Для себя я решил проблему с доступом через добавление в конфигурацию nginx’а следующих строк:
return 444; # вернёт пустой ответ.
Для своих сайтов я использую Cloudflare который прекрасно справляется с экранированием запросов и инициатор запросов никогда не получит ваш реальный IP адрес.
Не стоит думать что если между IP адресом вашего сервера и доменом была установлена связь, вас никогда не затронет проблема безопасности. У каждого разные причины для тех или иных поступков, будь то просто зависть или попытка устранить конкурента. Будьте бдительней, господа!
Ну а я после этого поста готовлюсь огребать минусы от «знатоков». Тем не менее, я сообщил о том о чём знал и теперь моя совесть чиста, надеюсь кому-нибудь да поможет.
Установка Ubuntu 20.04 на бесплатный VPS сервер от Oracle. Продолжение поста «Регистрируем Always Free VPS сервер для нужд Умного дома»
А мы, входим в свою панель управления VPS по ссылке которая вам пришла от Oracle после регистрации и переходим в первый блок, кликнув на «Создать экземпляр Compute«
Здесь нажимаем «Изменить«
В выпадающем окне в правом нижнем углу нажимаем «Изменить образ«
В открывшемся окне выбираем Canonical Ubuntu 20.04 Режим «Всегда бесплатно» применим
Спускаемся ниже, в настройках сети я ничего не меняю.
На следующем этапе нам нужно будет добавить ключ SSH, для дальнейшей авторизации через Putty. Для этого скачиваем с официального сайта весь пакет, в зависимости от разрядности вашей операционной системы на ПК или ноутбуке (Посмотреть можно «Мой компьютер» правой клавишей мыши «Свойства») и устанавливаем.
В открывшемся окне программы нажимаем «Generate» и водим мышкой или прокручиваем сколом, пока зелёная полоска наверху не завершит свой путь )))
Через несколько мгновений сгенерируется ключ, копируем его из верхнего окна
И вставляем в панели управления VPS в «Добавить ключи SSH» и нажимаем внизу «Создать«
Важно. Не
про..битепотеряйте его, ибо это фактически ключ для дальнейшего входа в только что созданную операционную систему, если потеряете, то придётся всё переустанавливать, способа восстановить или поменять в панели VPS я не нашёл.
Тем временем возвращаемся в панель управления VPS и видим, что наша система готова.
Копируем IP адрес своей операционной системе, это фактически IP адрес Вашей виртуальной машины.
Здесь в окне «Private key file for autorithashion» выбираем ранее сохранённый приватный ключ в формате *.ppk и нажимаем «Open«
Открывается терминал и всплывает окно, в котором нажимаем «Да»
Переключаем раскладку на английскую клавиатуру и вводим логин «ubuntu» (пароля пока нет) нажимаем «Enter».
и наконец ОБЯЗАТЕЛЬНО задаём пароль для входа в систему и ЗАПОМИНАЕМ! )))
Для этого пишем команду sudo passwd ubuntu нажимаем «Enter«.
Придумываем, запоминаем и водим пароль (при вводе никакие символы не отображаются) нажимаем «Enter«.
Ещё раз вводим пароль и нажимаем «Enter«.
Впереди много интересного на этом чёрном экране, как в этом эпизоде из фильма: )))
В следующем посте (ну это теперь, как только я отдохну от написанного и переварю всё сам. может на следующей недельке) в этой операционной системе мы поставим своего MQTT брокера для контроля датчиков IoT-устройств на ESP и их дальнейшей связки с умным домом.
А Вы тем временем можете поставить на неё тестовую систему умного дома Home assistant (ТЕСТОВУЮ! Ибо Умный дом нужно ставить на локальном сервере!), пока не решились на установку своего сервера или покупку какой-нибудь raspberry, сможете поставить VPN-сервер (Virtual Private Network) и/или прокси-сервер и можете проводить свои другие эксперименты.
Как всё это сделать в формате, как этот пост, я постараюсь написать как-нибудь в своих следующих публикациях, но по времени (когда) пока ничего обещать не буду.
Делаем собственное облако. OwnCloud+Let’s Encrypt
Наверняка вы пользуетесь какими-либо хранилищами данных в интернете. Если у вас есть почта в Gmail, значит автоматически у вас есть аккаунт в Drive.Google и именно там хранится ваша почта. Если почта от Yandex, то, точно также, вы используете Yandex.Диск. Есть еще множество вариантов облачных хранилищ. Есть платные и бесплатные, с разными характеристиками. Вы можете выбирать исходя из имеющейся задачи сохранения тех или иных данных. Но у всех этих хранилищ есть существенный недостаток — вы их абсолютно не контролируете. Кроме того, и это не секрет, те же Google и Yandex читаю вашу почту, просматривают ваши файлы для таргетирования рекламы. Менее именитые хранилища порой становились фигурантами утечек данных об аккаунтах пользователей, а значит хранимая в них информация подвергалась разной степени компрометации.
В общем очевидно, что неплохо было бы иметь собственное хранилище данных. Возможно не очень большое, но пригодное для хранения чувствительной информации. Конечно же подключение и обмен с таким хранилищем должны быть защищены. Само хранилище желательно расположить там, где до него не дотянутся Яровая и прочие Мизулины. Ну и хранимые файлы не блохо бы зашифровать. Вперед, к облакам!
В этой статье будет рассказано, как установить и настроить собственное хранилище на базе решения ownCloud. Нам подойдет любой VPS с количеством оперативной памяти от 512МБ. Вычислительные способности не очень важны, если пользоваться хранилищем будет малое число клиентов. А вот места на жестком желательно побольше. Сколько именно — решать вам. Применение SSD, опять же, при малом числе клиентов, не обязательно. Трафик тоже прикидывайте сами. Если у вас хранилище в районе 100ГБ, то и 512ГБ исходящего трафика в месяц будет достаточно. Важнее, чтобы реальная скорость канала была большая. Не стоит гнаться за тарифами с безлимитным трафиком, но с плохими каналами.
Небольшое отступление: Есть ответвление от ownCloud под названием Nextcloud. Он новее и прогрессивнее, но пока не блещет стабильностью и поддержкой. Ветки не сильно разошлись и Nexcloud настривается точно также. Для ознакомления и пробы сил я всё-таки рекомендую ownCloud. Он лучше документирован, по нему море статей, все баги и особенности давно разобраны.
Под ownCloud нам потребуется установить и настроить LEMP сервер. Устанавливать его мы будем на CentOS 7 x64. Желательно использовать дистрибутив с минимальным набором пакетов. Такой есть у любого хостера, называться будет примерно так: centos-7-x86_64-minimal. Все необходимые пакеты мы поставим в процессе настройки. Минимальный дистрибутив позволит избежать конфликтов пакетов и занятых портов.
Ещё нам понадобиться доменное имя. Второго или третьего уровня. Возможно у вас уже есть какой-нибудь домен. Тогда вы можете сделать поддомен вида, например, mycloud.example.com
Если у вас уже есть домен, то просто добавьте А запись, вида (вместо 123.123.123.123 вставить IP-адрес вашего VPS):
Если вы решили получить новый платный домент, то действуйте по инструкциям выбранного регистратора, а потом добавьте А запись, как показано выше.
Если ваш маленький еврей бунтует, то продолжим получать бесплатный домен у dot-tk
Как видите, я выбрал для домена такое немного колхозное, но понятное имя mydomen.ml (я знаю, что правильно mydomain, но все простые имена уже были заняты или платные). На его примере я и буду рассказывать дальше.
Так как у вас еще нет своего сайта/блога/etc, то вместо 123.123.123.123 вписываете IP-адрес вашего VPS.
Дальше вам предложат зарегистрироваться и домен за вами. Попадаем в clientarea
В принципе, мой домен уже смотрит на мой VPS и на этом можно было бы остановиться. Но это не правильно. ownCloud это сервис, один из многих, которые можно привязать к домену. Поэтому мы не будем тратить домен второго уровня на ownCloud, а сделаем как написано выше, домен третьего уровня.
Откроем консоль управления доменом.
Откроем управление DNS-записями
И добавим запись. Нужно заполнить новую запись в разделе Add Record (выделено красным). Вместо 123.123.123.123 вписываете IP-адрес своего VPS
Не забудьте нажать кнопку «Save Changes» под новой записью.
Так мы создадим домен третьего уровня, ведущий на наш VPS с ownCloud.
В дальнейшем, в том месте, где обведено зелёным, вы сможете написать другой IP. Например IP сервера с вашим сайтом.
Тогда домен mydomen.ml будет вести на сайт, а домен mycloud.mydomen.ml на VPS с ownCloud. Сейчас и тот и другой ведут на ваш VPS.
Мы будем использовать mycloud.mydomen.ml
Настройте SSH и подключитесь к серверу с помощью Pytty и WinSCP. Как это сделать, ищите здесь.
Выполним стандартные телодвижения по подготовке CentOS к работе:
Добавим репозиторий webtatic (предоставляет для CentOS пакеты, относящиеся к PHP):
Теперь установим PHP7-FPM и еще несколько дополнительных пакетов (в числе прочего будет установлен Redis), которые понадобятся в рамках этой статьи:
Проверим версию PHP, чтобы убедится, что всё хорошо встало
Должно быть примерно так:
С помощью WinSCP откроем файл /etc/php-fpm.d/www.conf и найдем строчки:
; RPM: apache Choosed to be able to access some dir as httpd
user = apache
; RPM: Keep a group allowed to write in log dir.
group = apache
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx
Проверяем, чтобы был именно порт 9000.
Сохраняем и закрываем файл.
Теперь сделаем рабочий каталог для PHP:
Назначим его владельцем пользователя nginx
Запустим php-fpm, redis и nginx
systemctl start redis
systemctl start php-fpm
systemctl start nginx
Убедимся, что с ними всё хорошо
systemctl status php-fpm
systemctl status nginx
systemctl status redis
И добавим в атозагрузку
systemctl enable php-fpm
systemctl enable nginx
systemctl enable redis
Теперь на нужна СУБД MariaDB. Установим:
И добавим в автозагрузку
Теперь выполним первоначальную настройку MariaDB:
Enter current password for root (enter for none):
просто жмём Enter. На вопрос:
отвечаем Y и жмём Enter, придумываем и два раза вводим стойкий пароль.
Навсе последующие вопросы отвечаем Y и жмём Enter.
Remove anonymous users? [Y/n] Y
Disallow root login remotely? [Y/n] Y
Remove test database and access to it? [Y/n] Y
Reload privilege tables now? [Y/n] Y
Создадим новую базу данных с названием ‘owncloud_db’ с пользователем ‘ownclouduser’.
СУБД спросит пароль, вводим пароль придуманный выше.
Вводим команду (не забывайте «;» )
В следующей команде вместо ownclouduser_pass придумайте, запомните и впишите стойкий пароль (да, ещё один).
create user ownclouduser@localhost identified by ‘ownclouduser_pass’;
Дадим пользователю права на новую базу (вместо ownclouduser_pass впишите пароль из предыдущей команды)
grant all privileges on owncloud_db.* to ownclouduser@localhost identified by ‘ownclouduser_pass’;
И отменим все другие права:
Чтобы выйти из консоли СУБД введите
Теперь настроим бесплатный сертификат Let’s Encrypt для нашего Nginx и автоматизируем его обновление.
Клонируем репозиторий проекта letsencrypt из GitH
Теперь создадим сертификат
ВНИМАНИЕ: к этому моменту ваш домен (в моём случае mycloud.mydomen.ml) уже должен пинговаться.
Чтобы это проверить, на компьютере с Windows нажимаем сочетание клавиш Win+R и вписываем
в ответ мы должны получить четыре строчки вида «Ответ от 123.123.123.123: число байт=32 время=79мс TTL=51». Если в ответ мы получаем «При проверке связи не удалось обнаружить узел…», то нужно просто подождать. После регистрации домена и добавление строчки с доменом третьего уровня может пройти до 24 часов, прежде чем они начнут пинговаться.
Выполним последовательно команды:
В процессе нас попросят ввести e-mail для уведомлений (вводим реально существующий):
Enter email address (used for urgent renewal and security notices) (Enter ‘c’ tocancel)
принять лицензионное соглашение (ввести A)
и ответить на вопрос об информационной рассылке (ввести Y или N, тут уж как сами хотите.)
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let’s Encrypt project and the non-profit
organization that develops Certbot? We’d like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
——————————————————————————-
(Y)es/(N)o:
В конце получим сообщение вида:
Congratulations! Your certificate and chain have been saved at…
Теперь сделаем ключ для алгоритма Диффи-Хелмана.
Процесс долгий. Занимает несколько минут.
Теперь научим наш Nginx применять полученные сертификаты, а также добавим некоторые настройки для ownCloud. Открываем конфиг Nginx по пути /etc/nginx/nginx.conf и находим в нем секцию, которая выглядит примерно так:
server <
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /usr/share/nginx/html;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / <
>
error_page 404 /404.html;
location = /40x.html <
>
error_page 500 502 503 504 /50x.html;
location = /50x.html <
>
>
Примечание:К сожалению возможностей пикабу не хватает для показа конфигов и скриптов с нормальным форматированием. В читаемом виде их можно найти в оргинале статьи.
Удаляем эту секцию и вместо неё вставляем секции следующего содержания:
upstream php-handler <
server 127.0.0.1:9000;
>
server <
# перенаправление с 80 порта, а также с www
server_name mycloud.mydomen.ml www.mycloud.mydomen.ml
listen 80;
return 301 https://mycloud.mydomen.ml$request_uri;
>
server <
listen 443 ssl;
server_name mycloud.mydomen.ml;
# Указываем пути к сертификатам
ssl_certificate /etc/letsencrypt/live/mycloud.mydomen.ml/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mycloud.mydomen.ml/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA’;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
# позволяем серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options «SAMEORIGIN»;
add_header X-XSS-Protection «1; mode=block»;
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
location
^/(?:build|tests|config|lib|3rdparty|templates|data)/ <
return 404;
>
location
^/(?:\.|autotest|occ|issue|indie|db_|console) <
return 404;
>
location
Смотрим внимательно в приведённый выше конфиг. Все mycloud.mydomen.ml заменяем на название своего домена.
Проверим, что всё хорошо
Должны получить в ответ:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Применим новые настройки
letsencrypt выдаёт сертификаты со сроком действия 90 дней. Их нужно заблаговременно продлевать. Процесс этот можно и нужно автоматизировать. Само обновление запускается командой
Если вы выполните эту команду прямо сейчас, то она проверит все ваши сертификаты и уведомит, что их продление не требуется.
——————————————————————————-
Processing /etc/letsencrypt/renewal/mycloud.mydomen.ml.conf
——————————————————————————-
Cert not yet due for renewal
The following certs are not due for renewal yet:
/etc/letsencrypt/live/mycloud.mydomen.ml/fullchain.pem (skipped)
No renewals were attempted.
Для автопродления воспользуемся встроенным в Linux планировщиком cron. Для этого командой
откроем crontab для редактирования. Появится пустое чёрное поле.
Нажмите кнопку Insert на клавиатуре, снизу появится уведомление —ISERT —. Теперь впишите/вставьте следующие две строчки
00 3 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log
10 3 * * 1 /usr/bin/systemctl reload nginx
Нажмите на клавиатуре кнопку Esc, режим —INSERT — пропадёт. Теперь введите (просто вводите, в нижней строчке оно появится само)
Мы вернемся в консоль с сообщением
crontab: installing new crontab
Теперь каждый понедельник ночью в 3:00 будет обновляться сертификат, а в 3:10 перезапускаться Nginx. Вы можете контролировать выполнение задания в логе /var/log/le-renew.log.
Это всё была присказка, т.е. только подготовка к установке ownCloud. Промежуточным итогом мы имеем Web-сервер, который умеет в правильный https, имеет все необходимые библиотеки и СУБД. Т.е. мы установили и настроили (ну почти) обещанный LEMP сервер.
Остановим пока Nginx
Узнать последнюю версию ownCloud и получить ссылку на скачивание можно здесь.
И скопируем туда файлы ownCloud
Теперь, с помощью WinSCP, в папке /root/ создадим файл oc-set со следующим содержимым:
И выставим ему права 0755.
После выполним полученный скрипт:
Скрипт отработает. Создаст все необходимые каталоги для ownCloud и выставит правильные права. В результате работы скрипта будут выведены строчки:
Теперь можно в браузере переходить по адресу cloud.mydomen.ml
Нас встречает окно создания учётной записи администратора
Придумываем логин-пароль администратора и нажимаем «Завершить установку». Пароль должен быть стойким.
Если вы сейчас зайдёте в наше вновьсозданное облако, то увидите, что ownCloud ругается на отсутствие кэширования, что может замедлять работу. Настроим кэширования с помощью Redis.
В WinSCP откроем файл /usr/share/nginx/html/config/config.php. Смотрим на последнюю строчку, она выглядит так:
Перед ней добавим строчки
‘filelocking.enabled’ => true,
‘memcache.local’ => ‘\OC\Memcache\Redis’,
‘redis’ => array(
‘host’ => ‘localhost’,
‘port’ => 6379,
‘timeout’ => 0.0,
),
запятые в конце строчек не забудьте.
Должно получиться так
‘filelocking.enabled’ => true,
‘memcache.local’ => ‘\OC\Memcache\Redis’,
‘redis’ => array(
‘host’ => ‘localhost’,
‘port’ => 6379,
‘timeout’ => 0.0,
),
);
Сохранить и закрыть.
С помощью WinSCP откроем файл /etc/sysctl.conf и добавим строчку:
Сохраним и закроем файл.
systemctl restart redis
systemctl restart php-fpm
systemctl restart nginx
Теперь можно в браузере заходим в наше облако cloud.mydomen.ml. Он будет ругаться на СУБД и пр. — не обращайте внимания, это для данной задачи не критично.
Обязательно зайдите в основные настройки и установите настройку планировщика задач на Cron
Облако настроено, можно пользоваться. Теперь настроим немного безопасности.
Установим и запустим файрволл
И откроем порты для необходимых сервисов
Проверим, что сохранилась возможность заходить по ssh и в браузере нормально открывается наше облако.
Добавим файрволл в автозагрузку
На этом настрока ownCloud завершена. Консоль putty и менеджер WinSCP нам больше не нужны.
В качестве последнего штриха включим шифрование наших файлов в хранилище. Заходим в настройки (Ищите свой логин в правом верхнем углу окна браузера. Там, в выпадающем меню «Настройки»). В разделе Администрирование открываем пункт «Приложения». Жмём кнопку «Показать отключённые приложения». Находим приложение «Default encryption module» и нажмём рядом с ним кнопку «включить».
Теперь Настройки->Администрирование->Шифрование. Ставим галочку «Включить шифрование на стороне сервера», читаем предупреждение и жмём в конце него «Включить шифрование». Ниже, в появившихся настройках модуля шиврования выбираем «Мастер-ключ» и применяем настройку. Нас попросят перелогинится, сделаем это. Опять идём Настройки->Администрирование->Шифрование и видим надпись
Для работы с облаком вам нужен клиент на вашем устройстве. Не рекомендую использовать для повседневного подключения к ownCloud созданную выше (при первом входе) учетную запись администратора. Оставьте её для администрирования. Щелкните по логину администратора в правом верхнем углу и выбирете «Пользователи» в выпадающем списке. В открывшемся окне, слева, добавьте группу для обычных пользователей. Например, назовите её Users. После создания группы в правой части окна, вверху, заполните данные на нового пользователя: логин, пароль (стойкий), группу (выбираем Users). Нажмите «Создать». В таблице добавиться строчка с новым пользователем. Установите ему квоту. Максимум, что вы можете выделить, это общий размер диска вашего VPS минус 3ГБ. Т.е. если у вас диск 100ГБ, в квоту вы можете вписать не более чем 97 GB. Всё, пользуйтесь новой учётной записью.
Клиентские приложения практически под все распространенные операционные системы можно найти здесь.
К сожалению, клиенты для мобильных устройств платные (копейки конечно, но тем не менее). Для Android бесплатный клиент здесь. Но нужно понимать, что он от стороннего разработчика. Для подключения вам понадобятся адрес сервера (в моём случае это https://mycloud.mydomen.ml) и логин-пароль. Настройка подключения элементарная, описывать не буду.
Данная статья конечно же не является исчерпывающей инструкцией по ownCloud. Но теперь вы уже знаете, что это такое и може продолжить изучение самостоятельно. Или оставить так. Текущей конфигурации достаточно для большинства персональных задач.
Если у вас есть вопросы, то все контакты для обратной связи вы найдёте здесь.