Удаленная переустановка CentOS 7 по сети без CD-ROM, носителей USB и ISO образов
Для всех читателей блога представляю подробную инструкцию как удаленно переустановить CentOS 7, когда из всех подручных средств есть только доступ к серверу по SSH. В сети достаточно рекомендаций по этому поводу, но к сожалению ни одна из них не является самодостаточным руководством.
Ранее я уже описывал алгоритм удаленной переустановки CentOS 6 https://moonback.ru/page/centos-remote-install.
Условия для успешной установки CentOS 7
Должны быть выполнены следующие условия:
- Сервер на базе CentOS 7;
- У сервера должен быть доступ в интернет, как минимум к репозиториям CentOS;
- У вас должен быть доступ к серверу по SSH протоколу (я использую SSH-клиент PuTTY) с правами привилегированного пользователя ROOT;
- Вы должны знать сетевые настройки сервера: IP адреса сервера, шлюза, DNS и маску сети;
- На рабочем компьютере должен быть установлен VNC клиент (UltraVNC, TightVNC).
Инструкция была протестирована на реальном виртуальном сервере в интернете и не содержит ошибок.
Необходимые файлы CentOS 7
Первое, что нам надо сделать, это скачать файлы ядра и RAM-диска нужного нам дистрибутива. Для этого подключимся к серверу по SSH и выполним следующее:
Эта операция может растянуться на 5..10 минут, так как суммарный размер файлов превышает 40 МБ.
Настройка GRUB2
В CentOS 7 используется GRUB2 и правила хорошего тона говорят о том, что все опции по загрузке надо вносить в файл /etc/grub.d/40_custom в соответствии с новым синтаксисом, не забывая при этом, что файл должен заканчиваться пустой строкой и нумерация разделов жесткого диска сместилась на единицу — первый раздел теперь 1, а не 0.
Но я поступил иначе… сразу редактируем файл /boot/grub2/grub.cfg, ищем первый блок в секции ### BEGIN /etc/grub.d/10_linux ### начинающийся с menuentry ‘CentOS Linux…. У меня он выглядел так:
Копируем этот блок в секцию ### BEGIN /etc/grub.d/40_custom ###
вставляя между строк:
# the ‘exec tail’ line above.
и
### END /etc/grub.d/40_custom ###
Затем, меняем название на NetInstall и редактируем последние строки. Должно получиться следующее:
- vncpassword=123456 — пароль для подключения с помощью VNC клиента (используйте другой);
- ip=193.170.128.128 — адрес вашего сервера;
- netmask=255.255.252.0 — маска сети;
- gateway=193.170.128.1 — адрес шлюза по-умолчанию;
- nameserver=193.170.128.2 — DNS сервер (думаю можно использовать DNS от Google 8.8.8.8) .
Подготовка к перезагрузке
Укажем серверу, что при следующей перезагрузке он должен использовать наш пункт меню:
Перезагрузка и установка CentOS 7
Перезагружаем сервер и идем пить кофе…
…так как объем загружаемых данных из репозитория CentOS составляет около 280 МБ, то не спешим и лишь минут через 15..20 пробуем подключиться VNC клиентом (UltraVNC, TightVNC) к нашему серверу по адресу: 193.170.128.128:1
вводим пароль, что указали в конфигурации меню загрузки…
…и выполняем установку в обычном режиме.
Но это уже совсем другая история…
Благодарности
При написании статьи были использованы следующие источники:
Сетевая установка Linux
Недавно столкнулся с установкой Centos 7 в необычных условиях.
Во-первых, дома. То есть имел дело с локальными компьютером, а не с сервером с IPMI.
Во-вторых, за неимением дискового привода обычно использую загрузочную флешку, которая в данном случае оказалась бесполезной, так как новый компьютер загружается только с флешек с инсталятором Windows. Проблема не новая, судя по отзывам о материнской плате.
В моем распоряжении осталась сеть. Приведу пример установки Centos 7 по PXE и iPXE
Как установить Linux через ipxe?
Как установить Linux через pxe?
Установка через PXE
Соединим ethernet кабелем компьютер1 — на котором будут DHCP, TFTP и компьютер2 — на который должна быть установлена ОС.
Добавим статичные настройки сетевого адаптера на компьютер1. Мой адрес 192.168.1.50.
Скачаем и установим TFTP. В этой программе настроим DHCP и TFTP сервер с которого отдадим IP адрес и установочные файлы компьютеру2.
Отключим брандмауэр и запустим tftpd с правами администратора. Выставим аналогичные установки, как на картинках. Возможно потребуется перезапуск tftpd.
На компьютере2 в boot меню выберем сетевой адаптер. В окне tftpd на компьютере1 будет отображаться шкала прогресса.
После этого, на компьютере2 загрузится окно инсталлятора ОС.
Установка Linux через iPXE
Скачаем образ ipxe.iso. Rufus-ом создадим загрузочную флешку на основе этого образа.
Выложим скрипт install.ipxe на любой веб сервер. О том, как поднять веб сервер на локальном компьютере можно узнать тут. Адрес моего скрипта будет таким sitename.ru/install.ipxe
Содержимое скрипта install.ipxe для установки Centos 7
#!ipxe
set base http://mirror.centos.org/centos/7/os/x86_64
prompt -k 0x197e -t 2000 Press F12 to install CentOS. || exit
kernel $/images/pxeboot/vmlinuz initrd=initrd.img repo=$
initrd $/images/pxeboot/initrd.img
boot
По аналогии с этим скриптом для установки Centos 7, можете подготовить свой скрипт для установки другой ОС.
Соединим компьютер, на который необходимо установить Linux, и роутер ethernet кабелем. Вставим флешку и загрузимся с нее. После нажатия F12 появится ipxe консоль. Используем следующие команды для получения IP адреса и скачивания скрипта
После этого загрузится окно инсталлятора ОС.
Дубликаты не найдены
О, видел ваш пост на хабре. Когда работал хелпдеском, поднял на дебиане связку pxe+tftp, по pxe раздавал клонзиллу, и в меню сделал шаблоны для бэкапа и восстановления, загнал в бэкапы винду с софтом без дров и раздавал по сети. По итогу, получалось по несколько компов разом готовить, только дрова доустанавливай. Был конечно WDE, но он был тем еще гемором
а еще раньше сделал такую же схему и заливал свой «дистр» на старые ноуты и компы для детдомов и т.п. Как-то с 2 друзьями получилось подготовить 200 ноутов за 3 часа, это еще с заменой хардов на ссд.
Я тогда еще выложил эту связку debian+pxe+tftp+dhcp+clonezilla в сети, назвал pxebian.
Опять херачат параллельно на Хабре и Пикабу. Недостаток лайков страдать заставляет?
Потому что недостаток лайков на здоровье не влияет.
Пишут не для того, чтобы кому-то что-то куда-то заходило. Делиться знаниями или мыслями это просто приятно. Но у каждого свое — кто-то бабку в метро встретил, а кто-то PXE настроил. И это может кому-то понравится, а может и нет. Знаете, даже у Deep Purple есть дизлайки на ютубе. Но это не мешает музыкантам выкладывать свои произведения на куче разных платформ.
я понимаю, что вы хотите сказать. Что пикабу исключительно для сисек, котиков и кастиара. Но отнеситесь к пикабу как к месту, где сидят разные люди, включая людей, заинтересованных в айти.
А сменить режим OS на Other OS слабо?
Бля, с винды линуха накатывать.
Мсье знает толк!
Как случайно написать Web-GUI для Haproxy
Современный мир системных администраторов обленил нас красивыми web-face-ами, что даже не охота ставить софт, где нет этого самого «гуя» (чувствую сейчас полетят камни от правоверных строчкеров), ну не через строку же постоянно туда лазить, правда? Все бы ничего, если софт поставил, настроил и забыл, а что делать, если туда надо постоянно лазить, править, ну и конечно же нет лога всех действий, не писать же каждый раз cp cfg cfg_back, со временем запутаешься и забьешь на это дело.
Много лет назад познакомился я с таким чудесным балансером, как Haproxy. Все чудесно и красиво. Стало у меня их много и задумался я о поиске GUI к нему, но его на удивление не было. Очень популярный софт, к тому же достаточно старый, ну да ладно подумал я и продолжил изредка править ручками в своем любимом vi и иметь кучу открытых вкладок со статистикой всех активных серверов. Но настало время и мне пришлось удовлетворять «хотелки» людей, которые писали софт для работы через http, вот тут и началось интересное…
Ручки зачесались, глазки загорелись и я приступил. Точнее начал думать на чем писать, вспоминать давно-давным забытый PHP, как-то не хотелось, да и казалось, что он не совсем подходит для этого дела. В итоге выбор пал на Python, в будущем точно пригодится подумал я и началось впитывание информации.
В начале задачи стояли не такие уж и сложные: возможность редактировать конфиги из веб интерфейса из одной точки входа, сохранения предыдущих версий конфигов. Данный, не особо большой функционал получилось реализовать достаточно быстро, но тут во мне взыграла то ли админская лень, то ли пресловутый перфекционизм и мне этого показалось конечно же мало. И тут начали появляться такие фичи как: сравнение двух конфигов, логирование всех действий связанных с конфигами, Runtime API и добавления секций, через web.
И как порядочный UNIX администратор живущий за счет свободного ПО я решил поделится с миром, а в друг кому-то пригодится? Но для этого надо было сделать все так, чтобы не приходилось лазить в код, но максимум в конфиг приклады(Сейчас большинство настроек переехало в базу. Как по мне их стало удобней редактировать и при обновлении не будет ошибок из-за отсутствия в конфиге какого-либо параметра).
Спустя месяц я выложил свою поделку на Github особо не на что не рассчитывая. А зря, софт оказался слегка востребованным и тут началось самое интересное… Активная «допилка» идет уже почти год. Порой есть желание все это бросить, т.к. мои потребности перекрыты уже давно. Ну вот зачем мне возможность развернуть «кластер» с keepalived и HAProxy через веб морду, если у меня это занимает от силы пару минут? А людям оказывается надо, да и мне интересно, и есть чем заняться. Хотя конечно же есть и нужные мне функции, например, как мониторинг бэкенд серверов, доступны ли они для Haproxy. У нас конечно же есть корпоративный мониторинг, но там сидят люди, которые могут достаточно долго реагировать, + т.к. мой отдел занимается разработкой и софт то появляется, то исчезает достаточно долго пробиваться через бюрократию.
А с недавних пор HAProxy-WI так же поддерживает NGINX и дает возможность установить полноценный мониторинг состоящий из Grafana, Prometheus, Nginx и HAProxy экспортеров. Так же появилась возможность простого мониторинга портов на предмет доступности порта, ответа HTTP и проверка ответа по ключевому слову. Да, не много функций, но зато ставить и админить легко 🙂
В общем решил поделится, ведь получается, что это единственный бесплатный GUI. А вдруг кому пригодится? И ссылка, вдруг кого заинтересует: https://github.com/Aidaho12/haproxy-wi/
Путь в администрирование linux
Всем привет! Возможно, тут есть люди, такие же как и я, которые работают эникейщиком(я уже таковым не являюсь), имеют слабые познания в администрировании, но хотели бы приобрести какие то навыки в администрировании linux и устроиться работать администратором систем linux. Порыскав интернете, я не нашел какого то готового стека заданий, который помог бы мне прокачать свой скилл администрирования, в основном это все советы, из разряда подними свой сервак, сделай на нем что нибудь и, может быть, у тебя что то получится, при этом не забудь, что он должен выдерживать массированные ддос атаки и high load проекты.
В общем, представляю вам мой стек заданий, который в свое время явно помог бы мне устроиться на работу, должность system administrator linux (junior):
1. Создать сервер с файлопомойкой на debian\ubuntu (можете так же CentOS)
2. Купить дешевый домен и поднять почтовый сервер
3. На нем же создать создать веб сервер nginx и разместить кастомный сайт WP + подключить ssl сертификаты от certbota. Так же можете попрактиковаться и сделать самоподписанные сертификаты и лично настроить nginx для работы с ними.
4. Настроить фаервол на подключение с одного лишь адреса и выдать доступ только к тем портам, которые требуют установленные приложения
5. Настроить бекап сервера
6. Поднять ipsec + strongswan для безопасного подключения по ssh
7. После все автоматизировать, перенеся все в ansible\puppet\cheff (если вы имеете навыки программирования, вам, вероятно, больше понравится puppet, но я рекомендую ansible, он в разы легче в освоении) и все занести в систему хранения git.
Так, так как для общего понимания, как устроено ядро и многое другое, всегда помогают книги. Я рекомендую Робачевский А.М. «Операционная система UNIX, 2 изд.», описано все довольно таки нудно, но все очень полезно и интересно, а так же, что немало важно, развернуто. Естественно, если у вас нет знакомого, которого можно спросить, не стесняйтесь юзать stackoverflow, unix stack exchange, qna habr. И гуглите, очень много гуглите. Так же каждая программа обладает manual page\—help, и качайте самый полезный навык для админа — поиск информации(утилиты grep\find и им подобные).
Каждый из 7-ми вопросов легко гуглится и ответ на каждый вопрос 100% можно найти на habr или digitalocean.
Это именно те знания, которые вам явно пригодятся для работы почти в каждой организации, которые требуют от linux system administrator. Естественно, этих знаний хватит лишь для старта, но самое главное, это не бойтесь что то делать и не стесняйтесь своих навыков, можете проситься на обучение в крупные IT конторы, они часто любят брать новичков на обучение(к слову, я так и попал в эту индустрию).
Буду рад каким либо правкам или советам. Спасибо за внимание.
Be an IT superhero)
Улыбнуло сообщение спланка при перезапуске)))
Восстановление удаленной папки на NAS с RAID-5
НЕ было бы счастья, да снова несчастье.
Имеется в моем хозяйстве NAS Thecus n16000pro , в нем 7 HDD *4 tb каждый под raid 5, имелась на нем папка с общим доступом куда пишутся проект с серверов интерпретации и геофизической обработки, так вот один не хороший человек взял вчера и затер папку, бэкап этой папки есть 2х недельной давности, но там был свежий материал.
1. отсутствие свежего backup по техническим обстоятельствам
2. Жизненная необходимость восстановления 2х папок из удаленной
Мои предположения по решению: Вынимаю диски , втыкаю в тачку гружусь в r-studio и собираю виртуальный raid потом пытаюсь восстановить данные, пока был найден один диск в массиве с переназначенными секторами и в умирающем немного состоянии, его я по секторно клонирую dd.
Кто нибудь бывал в подобной ситуации и как и какими средствами решал?
за свою жизнь 2 массива я так поднял рассыпанных но они были не из серии raid 5.
По ходу движений буду отписывать результаты сюда,
Кстати , всех с пятницей!
Делаем собственное облако. 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
Или же вы давно хотели заиметь свой домен (например для почты), но всё не решались. Тогда самое время перейти на сайт регистратора (godaddy.com, reg.ru и тысячи их. Не реклама!) и зарегистрировать доменное имя. Естественно, это будет стоить денег. Причем ежегодно. Можно получить доменное имя бесплатно. Например, перейдём на dot-tk (вместо — поставьте точку) и поищем свободное имя в зонах tk .ml .ga .cf .gq
Если у вас уже есть домен, то просто добавьте А запись, вида (вместо 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 к работе:
yum -y install epel-release
yum -y update
Добавим репозиторий webtatic (предоставляет для CentOS пакеты, относящиеся к PHP):
Теперь установим PHP7-FPM и еще несколько дополнительных пакетов (в числе прочего будет установлен Redis), которые понадобятся в рамках этой статьи:
yum -y install php70w-fpm php70w-cli php70w-gd php70w-mcrypt
yum -y install php70w-pear php70w-xml php70w-mbstring php70w-pdo
yum -y install php70w-json php70w-pecl-redis php70w-mysql
yum -y install dialog crontabs wget unzip redis git bc
Проверим версию 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.
;env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
;env[TMP] = /tmp
;env[TMPDIR] = /tmp
;env[TEMP] = /tmp
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
Сохраняем и закрываем файл.
Теперь сделаем рабочий каталог для 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. Установим:
yum -y install mariadb mariadb-server
И добавим в автозагрузку
Теперь выполним первоначальную настройку 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 часов, прежде чем они начнут пинговаться.
Выполним последовательно команды:
cd /opt/letsencrypt
./letsencrypt-auto certonly -a webroot —webroot-path=/usr/share/nginx/html/ -d mycloud.mydomen.ml
В процессе нас попросят ввести 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…
Теперь сделаем ключ для алгоритма Диффи-Хелмана.
openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
Процесс долгий. Занимает несколько минут.
Теперь научим наш 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
/.well-known <
allow all;
log_not_found off;
access_log off;
>
# The rest of your server block
root /usr/share/nginx/html;
index index.php index.html index.htm;
location = /.well-known/carddav <
return 301 $scheme://$host/remote.php/dav;
>
location = /.well-known/caldav <
return 301 $scheme://$host/remote.php/dav;
>
location /.well-known/acme-challenge < >
# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;
# Disable gzip to avoid the removal of the ETag header
gzip off;
# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;
location / <
rewrite ^ /index.php$uri;
>
location
^/(?:build|tests|config|lib|3rdparty|templates|data)/ <
return 404;
>
location
^/(?:\.|autotest|occ|issue|indie|db_|console) <
return 404;
>
location
^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) <
fastcgi_split_path_info ^(.+\.php)(/.*)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
>
location
^/(?:updater|ocs-provider)(?:$|/) <
try_files $uri $uri/ =404;
index index.php;
>
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location
* \.(?:css|js)$ <
try_files $uri /index.php$uri$is_args$args;
add_header Cache-Control «public, max-age=7200»;
# Add headers to serve security related headers (It is intended to have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into this topic first.
#add_header Strict-Transport-Security «max-age=15552000; includeSubDomains»;
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;
# Optional: Don’t log access to assets
access_log off;
>
location
* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ <
try_files $uri /index.php$uri$is_args$args;
# Optional: Don’t log access to other assets
access_log off;
>
>
Смотрим внимательно в приведённый выше конфиг. Все 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 и получить ссылку на скачивание можно здесь.
С помощью WinSCP удалим из папки /usr/share/nginx/html/ все папки и файлы кроме папки .well-known
И скопируем туда файлы ownCloud
Теперь, с помощью WinSCP, в папке /root/ создадим файл oc-set со следующим содержимым:
#!/bin/bash
ocpath=’/usr/share/nginx/html’
htuser=’nginx’
htgroup=’nginx’
rootuser=’root’
printf «Creating possible missing Directories\n»
mkdir -p $ocpath/data
mkdir -p $ocpath/assets
mkdir -p $ocpath/updater
printf «chmod Files and Directories\n»
find $/ -type f -print0 | xargs -0 chmod 0640
find $/ -type d -print0 | xargs -0 chmod 0750
printf «chown Directories\n»
chown -R $:$ $ /
chown -R $:$ $ /apps/
chown -R $:$ $ /assets/
chown -R $:$ $ /config/
chown -R $:$ $ /data/
chown -R $:$ $ /themes/
chown -R $:$ $ /updater/
chmod +x $/occ
printf «chmod/chown .htaccess\n»
if [ -f $/.htaccess ]then
chmod 0644 $/.htaccess
chown $:$ $ /.htaccess
fi
if [ -f $/data/.htaccess ]then
chmod 0644 $/data/.htaccess
chown $:$ $ /data/.htaccess
fi
И выставим ему права 0755.
После выполним полученный скрипт:
Скрипт отработает. Создаст все необходимые каталоги для ownCloud и выставит правильные права. В результате работы скрипта будут выведены строчки:
Creating possible missing Directories
chmod Files and Directories
chown Directories
chmod/chown .htaccess
Теперь можно в браузере переходить по адресу 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
Облако настроено, можно пользоваться. Теперь настроим немного безопасности.
Установим и запустим файрволл
yum -y install firewalld
systemctl start firewalld
И откроем порты для необходимых сервисов
firewall-cmd —permanent —add-service=http
firewall-cmd —permanent —add-service=https
firewall-cmd —permanent —add-service=ssh
firewall-cmd —reload
Проверим, что сохранилась возможность заходить по ssh и в браузере нормально открывается наше облако.
Добавим файрволл в автозагрузку
На этом настрока ownCloud завершена. Консоль putty и менеджер WinSCP нам больше не нужны.
В качестве последнего штриха включим шифрование наших файлов в хранилище. Заходим в настройки (Ищите свой логин в правом верхнем углу окна браузера. Там, в выпадающем меню «Настройки»). В разделе Администрирование открываем пункт «Приложения». Жмём кнопку «Показать отключённые приложения». Находим приложение «Default encryption module» и нажмём рядом с ним кнопку «включить».
Теперь Настройки->Администрирование->Шифрование. Ставим галочку «Включить шифрование на стороне сервера», читаем предупреждение и жмём в конце него «Включить шифрование». Ниже, в появившихся настройках модуля шиврования выбираем «Мастер-ключ» и применяем настройку. Нас попросят перелогинится, сделаем это. Опять идём Настройки->Администрирование->Шифрование и видим надпись
Для работы с облаком вам нужен клиент на вашем устройстве. Не рекомендую использовать для повседневного подключения к ownCloud созданную выше (при первом входе) учетную запись администратора. Оставьте её для администрирования. Щелкните по логину администратора в правом верхнем углу и выбирете «Пользователи» в выпадающем списке. В открывшемся окне, слева, добавьте группу для обычных пользователей. Например, назовите её Users. После создания группы в правой части окна, вверху, заполните данные на нового пользователя: логин, пароль (стойкий), группу (выбираем Users). Нажмите «Создать». В таблице добавиться строчка с новым пользователем. Установите ему квоту. Максимум, что вы можете выделить, это общий размер диска вашего VPS минус 3ГБ. Т.е. если у вас диск 100ГБ, в квоту вы можете вписать не более чем 97 GB. Всё, пользуйтесь новой учётной записью.
Клиентские приложения практически под все распространенные операционные системы можно найти здесь.
К сожалению, клиенты для мобильных устройств платные (копейки конечно, но тем не менее). Для Android бесплатный клиент здесь. Но нужно понимать, что он от стороннего разработчика. Для подключения вам понадобятся адрес сервера (в моём случае это https://mycloud.mydomen.ml) и логин-пароль. Настройка подключения элементарная, описывать не буду.
Данная статья конечно же не является исчерпывающей инструкцией по ownCloud. Но теперь вы уже знаете, что это такое и може продолжить изучение самостоятельно. Или оставить так. Текущей конфигурации достаточно для большинства персональных задач.
Если у вас есть вопросы, то все контакты для обратной связи вы найдёте здесь.