Мы предлагаем:У нас есть:
1 базу данных MySQL(50MB)PHP 5
Прикрепление своих доменовMySQL
Предустановленные движки сайтовPerl
Место под файлы(300MB)Ruby
Бесплатно и без рекламы!
Авторизация:
e-mail: Пароль:
Забыли пароль?    Запомнить  
Все блоги Администрация → О хостинге и его работе.
Rss

Здравствуйте, последнее время что-то наш хостинг немного “затух”, новых заявок мало, в основном старые пользователи сидят (за что им отдельное спасибо). Т.к. я в данный момент служу в ВС РФ, то и следить за состоянием сервера не могу, поэтому бывали довольно частые “502” и прочее. Автоматика работала изо всех сил, в основном благодаря ей и все работает. Собственно к чему я веду… Хостинг надо развивать, хоть мы и не отличаемся особой мощностью и стабильностью (хотя стараемся поддерживать стабильную работу), но пользователи есть, а значит надо работать дальше.

В целом планы на будущее такие (в идеале):
1. Новый сервер – крайне маловероятно т.к. денег на это все нет
2. Апгрейд текущего сервера (докинуть оперативки, жесткие диски пообъемнее поставить – вероятно, но не без помощи нашего Денис
3. Обновить всю программную часть (в частности операционку на сервере и все пакеты) – довольно долгая процедура т.к. Gentoo
4. Перейти с Gentoo на Debian – надоела долгая компиляция всего
5. Поменять некоторые “стандарты”, заложенные Денис и lupus`ом при создании всей внутренней структуры.
6. Настроить нормальную связку apache+nginx т.к. текущая не отличается особой производительностью.
7. Главную страницу обновить, здесь нужна помощь Павел по кодингу, а с моей стороны будет обеспечена программная поддержка со стороны сервера. Т.к. главная сейчас стоит на Ruby довольно старой версии, для начала надо все это перекинуть на RVM, чтобы со стороны сервера убрать старые пакеты.
8. Сделать нормальную админку для администраторов – нам тоже надо работать :)
9. Дать пользователям больше возможностей (а если будут жесткие диски побольше, то и места). В частности: доступ в консоль (ограниченную), что дает использовать git, composer, некоторые команды консоли для упрощения некоторых задач.
10. Ну и немного ограничить пользователя, а точнее сделать более жесткие квоты на место под файлы. Сейчас по сути оно не лимитировано, а только блокируется доступ к сайту.
11. Сделать нормальную систему слежения за работой сервера – не разрозненную как сейчас, а централизованно и чтобы охватывало всю возможную информацию о сервере.

Надеюсь на помощь пользователей (как предложения по улучшению, так и финансовую), а также на помощь наших администраторов Денис, Павел и остальных

Вот тут коротенький список дел: https://docs.google.com/document/d/1r89Ry4AkpRiExDFUfSsuCEQKFzi1gNfsYiNsvJaRZk0/
Помимо этого примерный план работ:

На мастере:
1. разобраться с загрузчиком
2. разобраться с Ruby (удалить старую версию с сервера, перейти на RVM)
3. Переход с simfs на ploop
4. Настройка серой сети между серверами
5. Поднять memcached +прокинуть на виртуалку
6. Разобраться с сессиями на главной
7. Удаление лишнего хлама
8. перенос логики с базы на скрипты (или оптимизация)
9. Смена паролей администратора баз и прочего
10. Переход с syslog-ng на rsyslog
11. Чистка БД от устаревших записей
12. Настройка мониторинга (текущая нагрузка (munin?), мониторинг сервисов (monit?/nagios?) + уведомления по всем каналам (sms/email/mesenger(skype/telegram/whatsapp)
13. Панель администратора (читай пункт 10 снизу)

На вебхосте
1. Квоты (инициализация квот для каждого существующего пользователя + для каждого нового, управление квотами)
2. Разработать структуру хоста + конфиги (апач+нгинкс)
3. Настройка серой сети между серверами
4. Смена паролей администратора баз и прочего
5. Прокси memcached
6. Оптимизация скриптов cron/logrotate
7. Переход с syslog-ng на rsyslog
8. Доступ к консоли для пользователей (+composer,git(?) что-то еще?)
9. Для прикрепленных доменов выпускать ssl сертификаты + их настройка с хоста
10. Интерфейс для управления сайтами пользователей (блокировка, уведомление о превышении квот, смена паролей (база, ftp), выпуск сертификата, блокировка доступа в консоль и фтп)
11. Чистка от устаревших сайтов
12. Настройка мониторинга (текущая нагрузка (munin?), мониторинг сервисов (monit?/nagios?) + уведомления по всем каналам (sms/email/mesenger(skype/telegram/whatsapp)

На вторичном ДНС
1. Разобраться с интернетом
2. Настройка серой сети между серверами
3. Мониторинг сервисов
4. Прокинуть доступ к БД на мастере через внутреннюю сеть
5. Настройка мониторинга (текущая нагрузка (munin?), мониторинг сервисов (monit?/nagios?) + уведомления по всем каналам (sms/email/mesenger(skype/telegram/whatsapp)


Автор: cyber01 | Дата создания: 01 апреля 2017, 17:00 UTC | 0.346
Теги: нет


Комментарии(16)
Арсений  01 апреля 2017, 17:57 UTC  #
0.0
0cfd0jeujkq

господи,я здесь уже почти шесть лет..шесть лет)

ya-72480  02 апреля 2017, 07:47 UTC  #
0.0
556-81997

Ребят. Спасибо, что вы есть. Самый адекватный из бесплатных хостинго. Увы я вырос из тематики своего сайта и забросил его. Прошу ускорить кго удаление (ибо больше не нужен). Надеюсь вы будете помогать людям и в дальнейшем. Вы супер)

arbuzmaster  02 апреля 2017, 17:34 UTC  #
0.0
Home01_1

Всем большое спасибо!

Павел  04 апреля 2017, 10:08 UTC  #
0.0
2bfe965ab5ef94a0568bc61c36b46d4c

Ох чёрт, сколько я пропустил.

Но я просто должен спросить, дата публикации играет какую-то роль? :D

Павел  05 апреля 2017, 10:20 UTC  #
0.0
2bfe965ab5ef94a0568bc61c36b46d4c
  1. Средства можно найти, но нужно знать объём. Стоит завести внутреннее обсуждение по этому поводу. Мне кажется, если столь радикально (см. след. пункты) менять инфраструктуру, стоит совместить это с переездом на новый сервер.
  2. Я так понимаю, это промежуточный этап, приведённый как более реалистичный вариант развития событий :)
  3. What could possibly go wrong… :D
  4. Интересно, что по этому поводу думает Денис, ведь Gentoo был выбран не просто так, наверное. Хотя в удобстве администрирования Debian явно будет получше.
  5. Не знаю, о чём речь, к сожалению.
  6. А вариант nginx+php-fpm не рассматривается? Или ещё есть серьёзные проблемы совместимости с тем, что у нас хостится? Так бы, может, вообще от Apache бы отказались.
  7. С радостью, но простым “обновлением” дело явно не обойдётся. Мы с Денисом некогда хотели просто взять и переделать нафиг главную, но зависли на системе рейтинга. У нас была мысль просто отказаться от “отфонарного численного показателя” (и расчёта весов) в пользу небольшого досье из ряда фактов, с ручным назначением привилегий (сообщество небольшое, можем себе позволить). Но потом мне нашлась работа и у меня не осталось времени продолжать разработку. Обидно.
  8. Если делать “морду” заново, можно сделать и отдельную админку, почему бы и нет.
  9. Опасное предприятие. Но если считаешь, что это можно сделать без большого риска для хостинга, ок. Я использовал какой-то веб-шелл, когда тестил здесь Laravel 4, он работал без доводки, но это жуткий костылище, конечно.
  10. Сделать каждому свой раздел в LVM и расширять по запросу? :)
  11. К сожалению, не знаю, какая с этим обстановка сейчас.
cyber01  07 апреля 2017, 16:31 UTC  #
0.0
Avatar

Павел отвечу также по порядку.
1 и 2 пункт можно совместить, текущий сервер особо сильно и не проапгрейдишь… Железо 2008 года, просто некуда пихать память и прочее (макс 8гб оперативки в этот сервер можно запихнуть). Тут выхода 2 – покупать сервер (дорого) + также как сейчас держать его на коллокейшене, либо арендовать (будет дороже чем коллокейшен и не будет абсолютно полного контроля над сервером (кто знает что взбредет владельцам сервера в голову)
3. В обновлении может пойти все не так, если часть, где пользовательские сайты я стараюсь держать более менее актуальной версии, то сам сервер не всегда есть возможность обновить,а нужно. Вот недавно столкнулся с проблемой, что в репах просто уже нет исходников нужного пакета, пришлось в архивах искать. Генту лучше обновить до доступного для старой версии, а потом уже новые пакеты кидать.
4. Генту гораздо более гибкая система, но на текущем сервере компиляция занимает довольно много времени (тот же php7 компилился минут 50, а на дебиане это пару минут времени скачать пакет)
5. Речь о структуре директорий, задачах при создании/пересоздании сайтов и прочем. Делалось тогда чтобы работало, а можно сделать оптимальнее и удобнее, но понадобится много времени и некоторый даунтайм.
6. Я бы с радостью, но тут для каждой CMS надо писать свои правила rewrite и прочее (комплект правил под популярные CMS у меня есть, но речь о другом), а это требует изменение конфига и последующего reload`а nginx, с apache проще, там есть .htaccess. Многие даже с .htaccess не могут справиться, не говоря уже о nginx. А связка nginx+php-fpm была бы быстрее и безопаснее в разы.
7. Ну я как минимум хочу сейчас снести с сервера ruby старый, ибо дырявый, но надо сначала главную на RVM перетащить
8. Можно и так, но опять же, кто этим будет заниматься…?
9. Есть изолированные оболочки, белый список программ и прочее, доступное в них. Думаю git/composer и прочее было бы кстати
10. Фигасе костыль :) Если не ошибаюсь, у LVM есть лимит на количество разделов. А решается это все обычными линуксовыми квотами, доступными в любой системе, а не как сейчас du + программная блокировка сайта.
11. В данный момент это все состоит из 2-3 инструментов (кстати мониторинг работает практически идеально) + бекапилка баз.

Все это я планировал сделать после возвращения из армии (3 месяца еще), многие действия (в частности пункты 3,5,7,9,10) могут привести к кратковременной (несколько минут) или долговременной (до часа) недоступности сайтов.

Вместо связки nginx+php-fpm (недоступной нам по причинам выше) можно отредактировать текущую связку nginx+apache+mod_php оптимальным образом, наброски уже давно есть,но возникли проблемы с правами доступа (нету в nginx аналога mod_ruid и разделения прав как у Apache-ITK)

Павел  09 апреля 2017, 23:01 UTC  #
0.0
2bfe965ab5ef94a0568bc61c36b46d4c

1..2. Смотря какой сервер. Надо прикинуть, какое железо в нём мы хотим, минимально. Прикинуть цены. Начать стоит с того, что у нас есть сейчас (а я даже этого не знаю).
3. О том и речь. Крупномасштабные обновления часто вызывают проблемы.
4. Ну, гибкость и удобство вещи слабосвязанные, а круг задач у нас для системы более-менее фиксированный. В общем, идею перехода на Дебиан лично я поддерживаю.
5. Окей. К сожалению, я совершенно не в курсе, что там внутри.
6. Точно, .htaccess… да, облом.
7. Дырявый у нас здесь не только Ruby… :D Но надо с чего-то начинать, да.
8. Ну, я могу заявлять о готовности сколько влезет, но это немаленький проект. Во время его реализации любые планы успеют измениться, возможно и не один раз.
9. Git всё-таки лишний (деплой его средствами лучше не организовывать, хоть это и кажется удобным), а вот composer был бы весьма полезен, да.
10. Да вроде бы нет, для LVM2-метаданных лимита уже нет, см. man vgcreate. Это было первое решение, что пришло в голову. Но тебе лучше знать, что проще поддерживать :)
11. Не смотрел туда, не могу комментировать :) Разве что замечу, что идея независимой бэкапилки мне нравится.

Добавлю тред:
12. Расширяться за пределы PHP есть планы? А то судя по подсказкам, раньше Окс поддерживал больше.

cyber01  11 апреля 2017, 18:00 UTC  #
0.0
Avatar

HP DL120 G5 вроде или Г7
4 гига оперативы, 2 диска по 500гб, проц хеон 2 ядра по 2.4
в общем у меня ноутбук мощнее

надо минимум гигов 16 оперативки, проц хотя бы ядра 4, жесткий не важно.
3. обновление потихоньку идет
4. перейти довольно проблемно будет, если вообще будет\
7.а что еще? озвучь (или сюда или в личку)\
10. заводить отдельные разделы, когда можно использовать стандартные квоты – лишнее.
11. мониторинг и статистика работы работают стабильно (munin и monit),а бекап баз делаю скриптом себе в яндекс. диск
12. остальное сложнее контролировать в отличие от php? но в планах есть. Я бы вообще перешел на нормальную панель управления, но это ломает всю концепцию.

Павел  20 апреля 2017, 06:28 UTC  #
0.0
2bfe965ab5ef94a0568bc61c36b46d4c

7. То, что обновлением не пофиксить :( См. п. 8.
10. Да не, я не всерьёз это предложил, конечно. Я было полез в ман по LVM, чтобы найти почему для нас это не сгодится, но сходу серьёзных ограничений не обнаружил, чему удивился. Квот нам хватит, конечно. Они ещё и лучше будут, на разделе-то часть места файловая система сожрёт, а квота это не будет учитывать, будет честнее к пользователям.
12. Да, это точно, сложнее. На какую, например?

turboblack  20 апреля 2017, 08:11 UTC  #
0.0
Portrejpj1

12. VestaCP – простая, и легкая

Павел  21 апреля 2017, 06:43 UTC  #
0.096
2bfe965ab5ef94a0568bc61c36b46d4c

12. VestaCP ничего кроме PHP не умеет, к сожалению.

cyber01  21 апреля 2017, 16:58 UTC  #
0.0
Avatar

Тот же ISPCOnfig как вариант, но там надо уже все перекраивать под нее.

cyber01  21 апреля 2017, 17:18 UTC  #
0.0
Avatar

Можно и свою реализацию конечно сделать, но надо много времени и в текущую панельку я внедрить не смогу.

А некоторые моменты можно и в инете подыскать

Андрей  24 апреля 2017, 15:54 UTC  #
0.0
Image

Привет, собратья! Ух, какая тут дискуссия идет!)))
Извините, давненько не был.

cyber01  25 апреля 2017, 08:51 UTC  #
0.0
Avatar

Андрей а ты как думал ?) Надо возвращаться :)

cyber01  25 апреля 2017, 08:51 UTC  #
0.0
Avatar

Прикинул план работ:
На мастере:
1. разобраться с загрузчиком
2. разобраться с Ruby (удалить старую версию с сервера, перейти на RVM)
3. Переход с simfs на ploop
4. Настройка серой сети между серверами
5. Поднять memcached +прокинуть на виртуалку
6. Разобраться с сессиями на главной
7. Удаление лишнего хлама
8. перенос логики с базы на скрипты (или оптимизация)
9. Смена паролей администратора баз и прочего
10. Переход с syslog-ng на rsyslog
11. Чистка БД от устаревших записей
12. Настройка мониторинга (текущая нагрузка (munin?), мониторинг сервисов (monit?/nagios?) + уведомления по всем каналам (sms/email/mesenger(skype/telegram/whatsapp)
13. Панель администратора (читай пункт 10 снизу)

На вебхосте
1. Квоты (инициализация квот для каждого существующего пользователя + для каждого нового, управление квотами)
2. Разработать структуру хоста + конфиги (апач+нгинкс)
3. Настройка серой сети между серверами
4. Смена паролей администратора баз и прочего
5. Прокси memcached
6. Оптимизация скриптов cron/logrotate
7. Переход с syslog-ng на rsyslog
8. Доступ к консоли для пользователей (+composer,git(?) что-то еще?)
9. Для прикрепленных доменов выпускать ssl сертификаты + их настройка с хоста
10. Интерфейс для управления сайтами пользователей (блокировка, уведомление о превышении квот, смена паролей (база, ftp), выпуск сертификата, блокировка доступа в консоль и фтп)
11. Чистка от устаревших сайтов
12. Настройка мониторинга (текущая нагрузка (munin?), мониторинг сервисов (monit?/nagios?) + уведомления по всем каналам (sms/email/mesenger(skype/telegram/whatsapp)

На вторичном ДНС
1. Разобраться с интернетом
2. Настройка серой сети между серверами
3. Мониторинг сервисов
4. Прокинуть доступ к БД на мастере через внутреннюю сеть
5. Настройка мониторинга (текущая нагрузка (munin?), мониторинг сервисов (monit?/nagios?) + уведомления по всем каналам (sms/email/mesenger(skype/telegram/whatsapp)


Простите, Ваш браузер не поддерживает html5
Управление стрелками. Пробел - пауза.