LINUX.ORG.RU
ФорумJob

Удаленное администрирование серверов


0

0

Возьму в администрирование еще некоторое количество серверов.

Администрирование удаленное, с абонентским обслуживанием. Первичная инсталляция бесплатно (при условии наличия договоренности о дальнейшем обслуживании). Средняя стоимость обслуживания от 3 тыс. руб до 10 тыс. руб в мес, в зависимости от задачи. Условия оплаты: ежемесячное перечисление на банковский счет.

Возможно проведение разовых работ. В этом случае схема оплаты и стоимость работ договорная.

Администрирую сервера

  • Баз данных (MySQL, некоторый опыт PostgreSQL);
  • Хостинг;
  • Шлюзы, NAT, Прокси;
  • Почта, Jabber, итп;
  • Виртуализация (OpenVZ);
  • Backup, VCS, итп

Debian

Основной дистрибутив - Debian (являюсь его действующим разработчиком). Все ПО будет устанавливаться из оффициальных репозитариев. Если Вам требуется что-то нестандартное (отсутствующее в Debian), то сделаю его стандартным (включенным в состав Debian), либо организую собственный репозитарий. Таким образом, если потребуется перевести сервер на администрирование штатным или другим человеком, то сделать это будет несложно.

Другие дистрибутивы

Возьму в администрирование сервер на любом другом дистрибутиве кроме Slackware и Gentoo. Если есть желание, проведу удаленную смену произвольного дистрибутива линукс на Debian (кроме расположенных в контейнерах VZ).

Документирование

По каждому серверу ведется документация, которая хранится в VCS, описывающая что где установлено, какие скрипты и для чего написаны, где хранятся, каким образом осуществляется интеграция ПО между собой, что нестандартного сделано на данном сервере, а так же список TODO.

Мои координаты

Постоянный адрес этого объявления в SVN: здесь.

★★

>Средняя стоимость обслуживания от 3 тыс. руб до 10 тыс. руб в мес

Что входит в эту сумму? Можно поподробнее?

Pantserovik
()

Хм... А сколько будет стоить разовая работа по включению в состав Debian пакета с cgit?

nnz ★★★★
()
Ответ на: комментарий от catap

>Для начала нужно выделить из git libgit.so ;)

Гнилая отмазка же. Все прекрасно знают, что этого никогда не будет.

Никто не мешает собирать cgit с той версией git, которая есть в соответствующем релизе, и жестко прописывать зависимость.
Никто... ну кроме нежелания поддерживать еще один пакет. Жаба задушила, в общем.

nnz ★★★★
()
Ответ на: комментарий от catap

Все уже украдено до нас: http://debian.stbuehler.de/

Но в официальные репы это не пропустят — как же, сопровождать ведь надо, пересобирать раз в полгода.

nnz ★★★★
()
Ответ на: комментарий от Pantserovik

Что входит в эту сумму? Можно поподробнее?

бесперебойная работа сервера 24/7 (все что в это понятие можно вложить), ну и обслуживание запросов заказчика которые он присылает по email вроде «завести новую БД» итп

rsync ★★
() автор топика
Ответ на: комментарий от nnz

Хм... А сколько будет стоить разовая работа по включению в состав Debian пакета с cgit?

RFP написан? напиши. может быть бесплатно соберем :)

rsync ★★
() автор топика
Ответ на: комментарий от rsync

Хорошо, со злыднями и супостатами, которые лезут на сервак боретесь? Антиспам для почты, фильтрация по IP, включая баны по количеству неудачных попыток входа в систему итд? То есть включает ли озвученная вами сумма работы по защите сервера?
Или все сводится к банальному - вот сервер, все работает, давай деньги?

Pantserovik
()
Ответ на: комментарий от catap

Для начала нужно выделить из git libgit.so ;)

на эту тему можно написать багрепорт в апстрим git, возможно таковой уже написан?

rsync ★★
() автор топика
Ответ на: комментарий от mukoh

Так вас там много или все-таки ты один?

разработчиков Debian? в России немного, а вообще много. Debian - мой JFF, git'ом сам пользуюсь активно (в частности для хранения конфигов), потому если этот cgit того стоит могу и взяться его помайнтенить. Ну а правильно оформленный RFP для интересного пакета сам по себе - наиболее короткий путь найти того кто возьмется майнтенить :)

rsync ★★
() автор топика
Ответ на: комментарий от Pantserovik

Антиспам для почты, фильтрация по IP

антиспам - да, грейлистинг - да, возможно собственные скрипты над грейлистингом/антиспамом - да, но фильтрация по IP - плохой путь. впрочем если заказчику надо - можно сделать.

То есть включает ли озвученная вами сумма работы по защите сервера?

включает. однако, разумеется, в каждом отдельном случае сумма определяется набором этих работ. то есть если вас постоянно и целеноправленно (именно вас) атакуют именно под вас перестраивают атаки/ддосы итп, то разумеется такой сервер потребует много постоянного внимания (атаковать-то полегче чем защищаться) и обслуживание будет дороже :)

с таким сталкивался пока только один раз в своей практике. ну и вроде нашли приемлемые решения

rsync ★★
() автор топика
Ответ на: комментарий от rsync

RFP написан?

Есть ITP, но его заблокировали под высосанным из пальца предлогом.

nnz ★★★★
()
Ответ на: комментарий от rsync

Фикус в том, что нет желания фиксировать интерфейсы. Пока это используется внутри git, случай если меняется API/ABI и cgit не работает, это уже проблемы не git team.

А так они просто свяжут себе руки. Позиция какая-то такая.

catap ★★★★★
()
Ответ на: комментарий от catap

ну теоретически можно сделать следующее:

у пакета cgit ставить точную версионную зависимость на пакет git, а libgit.a включить прямо в тарболл с исходниками cgit. то есть по сути у cgit будут в исходниках и исходники git но он типо будет самостоятельным пакетом. с ftpmaster'ом придется возможно пободаться но зааплоадить такое можно.

PS: а чем этот GUI лучше штатного что на перле в одном файле идет?

rsync ★★
() автор топика
Ответ на: комментарий от catap

Позиция какая-то такая.

ну в общем позиция понятна. кстати вариант есть такой: вложить исходники cgit прямо в исходники git и собирать одним пакетом. если что-то сломается - выкидывать cgit из аплоадов, по мере починки обратно вкладывать. примерно так собирают Debian-ядра с OpenVZ: то есть далеко не каждый аплоад пакета linux-2.6 производится с бинарными пакетами -openvz

rsync ★★
() автор топика
Ответ на: комментарий от rsync

>у пакета cgit ставить точную версионную зависимость на пакет git...

Да, это самый очевидный путь.

а чем этот GUI лучше штатного что на перле в одном файле идет?


Очень быстрый, хорошо подходит для слабых машин или нагруженных проектов. Например, на той машинке, где попсовый gitweb обрабатывает запрос секунд 15-20, cgit справляется за пару секунд. Кроме того, там есть кэширование, так что последующие запросы обрабатываются практически мгновенно.

кстати вариант есть такой: вложить исходники cgit прямо в исходники git...


Это имхо гораздо лучше, чем первый вариант.

nnz ★★★★
()
Ответ на: комментарий от rsync

git'ом сам пользуюсь активно (в частности для хранения конфигов),

А можно поподробней, пожалуйста. Используете etckeeper или «просто» git. И в двух словах, если не сложно, преимущества данного подхода (VCS для конфигов).

anton_jugatsu ★★★★
()
Ответ на: комментарий от anton_jugatsu

А можно поподробней, пожалуйста. Используете etckeeper или «просто» git. И в двух словах, если не сложно, преимущества данного подхода (VCS для конфигов).

когда-то я на хабре писал целую статью об этом, но потом на хабре запретили ставить минусы тупым статьям, а я их все равно ставил и меня забанили (с кармой +120 и рейтингом +350). ща статьи в свободном доступе нет.

в двух словах так:

на чекаут и аплипатч (в post-стадии) вешаем скриптик который выравнивает права до нужных нам (хранить в отдельном бранче права мне не понравилось)

и кладем конфиги в git.

далее получается:

  • документированная история правки конфигов
  • единое хранилище конфигов для многих хостов (это в основном относится к конфигам ~, если говорить о /etc, то по ним каждый хост уникален получается и кроме истории тут профита нет)
  • возможность отката к более старой версии
  • плюс, при использовании централизованного репозитария между несколькими хостами, имеем «бесплатный» бакап конфигов в git

получается разворачиваем новый хост например, git init/remote add/pull и у тебя все редакторы/подстветка/комплишены/прочее работает как на родном домашнем хосте.

недостатки:

  • git не умеет работать с правами файлов (приходится извращаться немного с хуками, либо с бранчами)
  • безопасность: если конфиг-файл хранит какие-то ключи/пароли, то доступ к git-репозитарию должен контроллироваться тщательно
rsync ★★
() автор топика
Ответ на: комментарий от nnz

Это имхо гораздо лучше, чем первый вариант.

это надо по пути идти такому: писать в git-team предложение о том что «вот так вот будем майнтенить» и предлагать свои услуги по сопровождению этой части.

то есть надо с конкретным патчем выходить :)

rsync ★★
() автор топика
Ответ на: комментарий от rsync

Спасибо за развёрнутый ответ. Жаль статья та не сохранилась :( Я понял вы акцент делать на ~/, а для /etc используете, конкретно, можно создать, например, бранч для экспериментов и т.д. И что скажите про etckeeper?

anton_jugatsu ★★★★
()
Ответ на: комментарий от anton_jugatsu

И что скажите про etckeeper?

он держал права в отдельном бранче. Это не очень красиво ложилось на использование бранчей в собственно /etc. Соответственно я его отбросил сразу. Хотя после этого прошло много времени и я на куче форумов видел отзывы что etckeeper часто и сильно меняется. Какая ситуация там теперь - не знаю.

мне git + скрипт (который лежит в этом же git) который расставляет права после checkout и aplypatch вполне хватает. скрипт я вызываю из хуков, поэтому получется только первичная настройка git на хосте отнимает внимание, а дальше все в полном фоне (ну разве что появляется новый пакет с новыми файлами которые требуют жестко установленных прав доступа)

кстати git хранит в свойствах файла аттрибут x. надо бы залезть в его исходники и покопаться можно ли туда другие атрибуты прикрутить. чтобы по умолчанию не хранил, но при необходимости включить можно было.

Линус Торвальдс был против хранения атрибутов файлов в git, но если это сделать опционально, то может и примет? тогда вообще никакие велики над git будут не нужны.

rsync ★★
() автор топика
Ответ на: комментарий от rsync

Most VCS, including git, mercurial and bazaar have only limited tracking of file metadata, being able to track the executable bit, but not other permissions or owner info. (darcs doesn't even track executable bits.) So file metadata storage is stored separately. Among other chores, `etckeeper init` sets up a `pre-commit` hook that stores metadata about file owners and permissions into a `/etc/.metadata` file. This metadata is stored in version control along with everything else, and can be applied if the repo should need to be checked back out.

А ну они ушли от бранчей и пришли к тому же что и я на коленке сделал.

Только я как-то опасаюсь вызывать это все из apt'овых хуков. Мне никогда не нравилась идея разного рода автоматизированных коммитов в VCS файлов. и кстати держать весь etc в git тоже не стоит, там есть много файлов которым в VCS не место. У меня основная идеология такая: если я файл исправляю, то это кандидат на git add. Если используется дистрибутивный, дефолтный вариант, то в git файлу вроде и нечего делать

rsync ★★
() автор топика
Ответ на: комментарий от rsync

мне git + скрипт (который лежит в этом же git) который расставляет права после checkout и aplypatch вполне хватает. скрипт я вызываю из хуков, поэтому получется только первичная настройка git на хосте отнимает внимание, а дальше все в полном фоне (ну разве что появляется новый пакет с новыми файлами которые требуют жестко установленных прав доступа)

А не поделитесь скриптом :)

anton_jugatsu ★★★★
()
Ответ на: комментарий от anton_jugatsu

ну примерно так:

http://paste.org.ru/?qq44vp

  • то есть пускаем с параметром save - оно сохраняет доступы на все файлы, что лежат в git,
  • пускаем с параметром -h - показывает справку
  • пускаем без параметров - восстанавливает сохраненные доступы

на сохранение доступов я файл пускаю обычно вручную (поскольку права редко меняются), но можно наверное из хука pre-commit а на чтение из вышеописанных хуков.

ну и функционал получился тот же что у etckeeper. может работает не так быстро, но в общем приемлемо

rsync ★★
() автор топика
Ответ на: комментарий от rsync

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

rsync ★★
() автор топика
Ответ на: комментарий от anton_jugatsu

меня что-то поддостала его медленная работа, я переписал на перле, теперь работает быыыстро. если интересно то вот

http://paste.org.ru/?f2660e

заодно теперь хранит права и на каталоги тоже (некоторым прогам это важно) - все собирался собирался пофиксить, да руки не доходили

rsync ★★
() автор топика
Ответ на: комментарий от rsync

Ах, там немного неверный принт в начале скрипта был (то есть со скриптом все в порядке, а информацию о том куда сохраняются доступы он неправильно пользователю сообщал)

поправленное тут

rsync ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.