Linux как сервер приложений

8. Linux как сервер приложений

Linux как сервер приложений

По своей природе Linux предназначен для работы в качестве файл-сервера, сервера печати или сервера Intranet и является полнофункциональным сервером приложений. При работе с сервером приложений, приложения в действительности выполняются на сервере и лишь отображаются на терминале или рабочей станции, используя протокол X Windows или связь с терминалом, например Telnet. В типичных сетях Windows приложения выполняются на рабочей станции, а данные сохраняются на сервере и передаются с сервера на рабочую станцию.

Централизованное выполнение ряда приложений более эффективно. Кроме того, сервер приложений позволяет легко осуществлять контроль за работой программ. В сетях Windows или Novell система под управлением Linux может работать как сервер приложений, выполняя следующие функции.

• Выполнение программ с символьным интерфейсом, например мощного почтового программного обеспечения Unix/Linux.
• Поддержка пользовательских символьных интерфейсов для централизованных баз данных Linux.
• Осуществление доступа к выполняющимся в среде Unix/Linux внутренним приложениям, таким, как корпоративная телефонная книга.

Если Х-сервер инсталлирован на рабочей станции под управлением Windows, можно осуществлять централизованное управление приложениями X Windows с рабочей станции, в то время как сами приложения выполняются на сервере приложений Linux.

Linux поддерживает развитые сети с графическим интерфейсом пользователя (GUI) без программного обеспечения Windows 95/98/Ме или NT/2000. Подобное решение представляет интерес для организаций с небольшим бюджетом. Например, автор развернул сеть из 10 рабочих станций, работающих исключительно под Linux. Рабочие станции представляли собой машины типа IBM PC AT 486 с 8 Мбайт RAM. Запуск Windows с Microsoft Office на таких компьютерах был проблематичным, а стоимость необходимого лицензионного программного обеспечения составила бы более 300 $ на рабочую станцию.

Но с Linux на старом аппаратном обеспечении эти системы могут работать как простые X-терминалы, отображая приложения, которые выполняются на единственном сервере приложений. В этом случае сервером приложений может быть система Pentium 200 МГц с 96 Мбайт RAM. Единственное, за что надо заплатить в лицензионном программном обеспечении, — это офисный пакет программ Unix для того количества-дюльзователей, которые будут его использовать.

Сеть, подобная этой, может организовать эффективную работу пользователя, подобно системе Pentium с 32 Мбайт RAM под управлением Windows 95/98/Ме. Все управление программным обеспечением, счетами пользователя, резервированием данных и сопровождением системы может выполняться централизованно на одном или двух серверах.

Конечно, это решение подразумевает основное стратегическое правило: не использовать популярные приложения Windows. Когда существенна стоимость или недоступны современные аппаратные решения, Linux становится сильным кандидатом для организации распределенной компьютерной платформы.

Источник

Разворачиваем и демонизируем ASP.NET Core приложение под Linux в виде фонового сервиса

Подготовка окружения

Для начала, добавим dotnet-репозиторий:

На выходе получаем примерно следующее:

Теперь обновим индекс наших пакетов:

Далее, мы можем просто установить dotnet-пакет при помощи apt-get:

Теперь можем смело приступать к созданию приложения

Создание приложения

При помощи команды dotnet new мы можем создать шаблон для нашего приложения, подобно шаблонам из Visual Studio. Подробная документация к команде.

На текущий момент (07.2017), команда dotnet new поддерживает следующие шаблоны:

Мы создадим веб-приложение ASP.NET Core:

На выходе консоль выдаст нам следующее сообщение:

Чтобы убедиться, что шаблон сгенерировался правильно, заглянем в содержимое папки при помощи команды ls -la .

Все необходимые папки для сборки приложения на месте, приступим! Для начала, восстановим все пакеты при помощи dotnet restore .

Теперь можем собрать приложение:

Запустим приложение с помощью:

Консоль говорит нам, что приложение запустилось по адресу localhost:5000/. Проверим:

Желающих подробнее узнать, как работает web-сервер отсылаю к официальному источнику.

Теперь убьём процесс нажав Ctrl + C и опубликуем приложение командой dotnet publish. Эта команда упаковывает приложение и все его зависимости для дальнейшего развёртывания (желающим интимных подробностей сюда).

В случае проблем с правами доступа Вам поможет команда sudo chmod и эта страница документации.

Развертывание на сервере.

Если мы хотим развернуть наше приложение под linux-сервером, необходимо настроить прокси и демонизировать процесс запуска приложения. Для проксирования мы будем использовать nginx, для демонизации процесса systemd. Краткое описание утилиты

Как следует из документации выше, с asp.net core в коробке идет kestrel — веб-сервер для asp.net приложений. Зачем нам тогда нужен прокси-сервер? Ответ даётся на официальной странице Microsoft:

Если вы выставляете ваше приложение в интернет, Вы должны использовать IIS, Nginx или Apache как обратный прокси-сервер.

Обратный прокси-сервер получает HTTP запросы из сети и направляет их в Kestrel после первоначальной обработки, как показано на след диаграмме:

Главная причина, по которой следует использовать обратный прокси сервер — безопасность. Kestrel относительно нов и ещё не имеет полного комплекта защиты от атак.

Ещё одна причина, по которой следует использовать обратный прокси-сервер — наличие на сервере нескольких приложений, использующих один порт. Kestrel не поддерживает разделение одного порта между несколькими приложениями.

Так же, использование обратного прокси-сервера может облегчить распределение нагрузки и поддержку SSL.

Как говорилось выше, в качестве прокси-сервера мы будем использовать nginx.

Т.к. в качестве прокси-сервера у нас используется не IIS, следует добавить следующие строки в метод Configure файла Startap.cs.

Здесь мы включаем поддержку ForwardedHeaders мидлвера из пакета. Microsoft.AspNetCore.HttpOverrides, который будет вставлять в Http-запрос заголовки X-Forwarded-For и X-Forwarded-Proto, использующиеся для определения исходного IP адреса клиента и передачи его прокси-серверу. Определение мидлверов и практическое использование так же будет рассмотрено в дальнейших частях этого гайда.

Если у Вас nginx не установлен, выполните следующую команду.

и запустите его командой:

Далее, нам необходимо сконфигурировать nginx для проксирования http-запросов.

Создадим файл /etc/nginx/sites-available/aspnetcore.conf. Папка sites-avalible укахывает nginx-у, какие веб-сайты доступны на текущем сервере для обработки. Добавим в него следующие строки:

Создадим символическую ссылку на aspnetcore.conf в папку sites-enabled, в которой отражаются запущенные nginx-ом сайты.

Nginx настроен на то, чтобы принимать запросы с localhost:8888. Перезапускаем nginx командой sudo service nginx restart , чтобы созданные нами конфигурационные файлы вступили в силу. Проверяем:

502-я ошибка говорит, что сервер перенаправляет нас в другое место и в этом месте что-то пошло не так. В нашем случае — я убил процесс с нашим веб-приложением, которое было ранее запущено командой dotnet run. Потому что могу 🙂

На самом деле, потому что запускать dotnet run в консоли и вечно держать эту вкладку открытой грустно. Именно поэтому процесс будем демонизировать, то есть настроем автозапуск после перезагрузки и автоматическую работу в фоне с помощью systemd.

Для этого создадим файл в директории /etc/systemd/system/ с расширением .service

Назовём его kestrel-test:

И положим в него следующее содержимое:

[Unit]
Description=Example .NET Web API Application running on Ubuntu

[Service]
WorkingDirectory=/home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish #путь к publish папке вашего приложения
ExecStart=/usr/bin/dotnet /home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish/test-lesson.dll # путь к опубликованной dll
Restart=always
RestartSec=10 # Перезапускать сервис через 10 секунд при краше приложения
SyslogIdentifier=dotnet-example
User=root # пользователь, под которым следует запускать ваш сервис
Environment=ASPNETCORE_ENVIRONMENT=Production

Теперь включим и запустим сервис при помощи следующих команд:

Проверим статус сервиса:

Если всё было сделано правильно, на эта команда выдаст нам следующее:

Источник

Домашний linux сервер своими руками

Хочется поделиться с хабросооществом информацией о том как я собирал домашний сервер.

Из софта на домашнем сервере будет «крутиться» следующий набор:

• torrent клиент с web-мордой
• DHCP — раздаем ip адреса и сетевые настройки
• TFTP — для сетевой загрузки
• OpenVPN — для хождения в сеть с нетбука из недоверенных сетей
• FTP/Samba/NFS — сетевые шары для доступа с домашних машин
• Radius — для WPA2 авторизации
• DigiTemp — мониторинг домашней температуры

Аппаратная часть

При выборе аппаратной части, вариантов было несколько:

• старенький комп
• самосбор на базе mini-ITX
• тонкий клиент HP T5000
• тонкий клиент на базе Neoware CA2

Первый вариант был сразу же отброшен из-за шума, пыли и энергопотребления. Второй был заказан, пока шли комплектующие, я успел передумать (захотелось шум и энергопотребление свести до минимума). В итоге, на Ebay были куплены тонкие клиенты HP t5000 и Neoware CA2. Месяц спустя пришли тонкие клиенты и из двух, после долгих размышлений, был выбран Neoware CA2. В него идеально поместился 2.5′ HDD и вторая сетевая карта.

После допиливания, в буквальном смысле, Neoware CA2 я принялся ставить на него Ubuntu 9.10 с офисного TFTP сервера. Установку производил самую минимальную. Если бы не было набора для сетевой установки, ставил бы Debian с USB CD-ROM и netinstall диска. Сам я ярый фанат RHEL/CentOS, но на домашний сервер решил ставить что-то из debian семейства, для расширения кругозора.

Torrent клиент и вебморда

Теперь перейдем к установке torrent клиента и вебморды. Была выбрана связка rtorrent + rutorrent, установка из репозитариев была отметена сразу, т.к. «родной» пакет был собран без xmlrpc-c который расширяет функционал rutorrent. Ниже фактически, скрипт для авто-установки rtorrent+rutorrent+lighttpd+php.

Устанавливаем всё что необходимо для компиляции xmlrpc-c, libtorrent, rtorrent
apt-get install checkinstall subversion build-essential make autoconf autotools-dev automake libtool libcurl4-openssl-dev libsigc++-2.0-dev pkg-config libncurses5-dev
apt-get remove rtorrent libtorrent11 libxmlrpc-c3 libxmlrpc-c3-dev libxmlrpc-core-c3 libxmlrpc-core-c3-dev

Компилируем и «заворачиваем» в .deb пакет xmlrpc-c, libtorrent, rtorrent
svn co xmlrpc-c.svn.sourceforge.net/svnroot/xmlrpc-c/advanced xmlrpc-c
cd xmlrpc-c
./configure —prefix=/usr && make && checkinstall -D

cd ..
wget libtorrent.rakshasa.no/downloads/libtorrent-0.12.6.tar.gz
tar zxfv libtorrent-0.12.6.tar.gz
cd libtorrent-0.12.6
rm -f scripts/.m4 # для Debian
./autogen.sh && ./configure —prefix=/usr && make && checkinstall -D

cd ..
wget libtorrent.rakshasa.no/downloads/rtorrent-0.8.6.tar.gz
tar zxfv rtorrent-0.8.6.tar.gz
cd rtorrent-0.8.6
rm -f scripts/.m4 # для Debian
./autogen.sh && ./configure —with-xmlrpc-c —prefix=/usr && make && checkinstall -D

К сожалению, rtorrent не умеет работать в режиме daemon, по этому будем использовать screen
apt-get install screen -y
wget libtorrent.rakshasa.no/raw-attachment/wiki/RTorrentCommonTasks/rtorrentInit.sh —output-document=/etc/init.d/rtorrent
chmod +x /etc/init.d/rtorrent
sed -i ‘s/»user»/»torrents»/’ /etc/init.d/rtorrent
update-rc.d rtorrent defaults
useradd -d /torrents -m torrents

Создаем конфиг и папки для сессий и готовых торрент закачек, после чего стартуем rtorrent.
mkdir /torrents/.rtorrent_session
cat >> /torrents/.rtorrent.rc

Теперь займемся вебмордой rutorrent. Для работы rutorrent необходим вебсервер и интерпретатор php.
apt-get install lighttpd php5-cgi php5-cli php5-curl curl -y
lighty-enable-mod fastcgi
echo ‘server.modules += ( «mod_scgi» )’ >> /etc/lighttpd/lighttpd.conf
cat >> /etc/lighttpd/lighttpd.conf
( «127.0.0.1» =>
(
«host» => «127.0.0.1»,
«port» => 5000,
«check-local» => «disable»
)
)
)
EOF
/etc/init.d/lighttpd force-reload

Вебсервер готов, теперь будем ставить rutorrent и несколько полезных плагинов к нему.
cd /var/www/
svn checkout rutorrent.googlecode.com/svn/trunk/rutorrent
cd /var/www/rutorrent/plugins/
svn checkout rutorrent.googlecode.com/svn/trunk/plugins/tracklabels
svn checkout rutorrent.googlecode.com/svn/trunk/plugins/cookies
svn checkout rutorrent.googlecode.com/svn/trunk/plugins/autotools
svn checkout rutorrent.googlecode.com/svn/trunk/plugins/erasedata
chown -R www-data:www-data /var/www/

Теперь можно заходить по server_ip/rutorrent и начинать пользоваться.

Теперь установим DHCP сервер и создадим для него конфиг таким образом чтобы клиенты получали:
router 192.168.1.1
dns сервер 8.8.8.8
сервер времени time.nist.gov
tftp сервер 192.168.1.1
и для примера фиксированная выдача 192.168.1.100 клиенту с MAC-адресом 00:1B:FC:33:F0:25
aptitude install dhcp3-server
cat >> /etc/dhcp3/dhcpd.conf
строчки с option-150 нужны для моего VoIP телефона Cisco 7940.

TFTP и сетевая установка

aptitude install xinetd atftpd atftp

cat >> /etc/xinetd.d/tftp
Теперь проверим, работает ли tftp сервер
root@dvr:

# echo bla > /tftpboot/123
root@dvr:

# atftp 127.0.0.1
tftp> get 123
tftp>
root@dvr:

# cat 123
bla

Всё нормально, теперь создадим netinstall наборы для нескольких ОС: Ubuntu karmic, Ubuntu lucid, Debian lenny, Debian sid, Debian squeeze, Fedora 13, CentOS 5.5, Mandriva 2010.0, Suse 11.2, Slackware 13.1, Hardware Detection Tool, memtest и MHDD. Для этого предлагаю использовать слегка модифицированный скрипт который я взял с HowtoForge.
apt-get install lftp -y

wget itblog.su/tftpboot_installs.sh
bash tftpboot_installs.sh

Теперь добавим SystemRescueCd в PXE меню
wget «http://downloads.sourceforge.net/project/systemrescuecd/sysresccd-x86/1.6.3/systemrescuecd-x86-1.6.3.iso?use_mirror=citylan»
mount -o loop systemrescuecd-x86-1.6.1.iso /mnt/
cp /mnt/sysrcd.* /var/www/
cp /mnt/isolinux/initram.igz /tftpboot/
cp /mnt/isolinux/rescuecd /tftpboot/

cat >> /tftpboot/pxelinux.cfg/default
Без особого труда в это меню можно добавить продукты Acronis, инсталляцию и запуск Windows XP и прочее.

Вот так будет выглядеть наше меню:

Продолжение в следующей части. А именно:

• OpenVPN сервер для «хождения» в сеть из не доверенных сетей (например из гостиницы)
• FTP/Samba/NFS сетевые шары
• Radius для авторизации wi-fi клиентов
• DigiTemp зачатки умного дома, мониторинг температуры в квартире и за окном
• festival — говорящий будильник
• бакапы с хостинга

и подытожит статью скрипт который всё это установит в «два клика».

С удовольствием выслушаю замечания и дополнения.

Источник