Home

Создаём свой freebsd svn mirror

Subversion из портов мы уже поставили.

Теперь выбираем директорию, где у нас будет лежать база svn.

# mkdir -p /usr/home/svnmirror/
# cd /usr/home/svnmirror/

Дальше идём сюда ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ и выбираем тут файлы с самым большим номером релиза svn-репозитория. Потом меньше времени и трафика потребуется, чтобы синхронизировать базу до актуального состояния.

# fetch ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/svnmirror-base-r238500.tar.xz
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/svnmirror-doc-r39237.tar.xz
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/svnmirror-ports-r301235.tar.xz

Дальше распаковываем эти архивы.

# tar xvzf svnmirror-base-r238500.tar.xz
# tar xvzf svnmirror-doc-r39237.tar.xz
# tar xvzf svnmirror-ports-r301235.tar.xz

Теперь нужно это всё засервить в сеть.

Можно делать через apache. Ищи в интернетах setting up freebsd svn apache.

Я буду делать через svnserve.

Добавляем группу через vi /etc/group

svnserve:*:3690:

Добавляем юзера svnserve через добавление строки через vipw. Номер юзера по приколу сделал таким же, как и номер порта.

svnserve:*:3690:3690::0:0:svnserve:/home/svnmirror:/usr/sbin/nologin

Переписываем права доступа на директорию с базами:

# chown -R svnserve:svnserve /home/svnmirror/

Теперь самое долгое - синхронизировать базы. Можешь пропустить этот шаг. Потом оно обновится автоматически по cron'у. Если хочешь запустить последовательно все три команды, то объедини их с помощью &&.

# svnsync sync file:///home/svnmirror/base/
# svnsync sync file:///home/svnmirror/doc/
# svnsync sync file:///home/svnmirror/ports/

По дороге добавим задачу в cron. Чтобы оно на фоне обновилось. Время поставь другое, если надо.

Создадим файл по обновлению баз:

# vi /home/svnmirror/svnmirror.up.sh

Вставим в него строки: 

#!/bin/sh
/usr/local/bin/svnsync --trust-server-cert --non-interactive sync file:///home/svnmirror/base/
/usr/local/bin/svnsync --trust-server-cert --non-interactive sync file:///home/svnmirror/doc/
/usr/local/bin/svnsync --trust-server-cert --non-interactive sync file:///home/svnmirror/ports/

Проставим права на этот файл.

# chown svnserve:svnserve /home/svnmirror/svnmirror.up.sh
# chmod +x /home/svnmirror/svnmirror.up.sh

Допишем в крон задачу для пользователя svnserve (создадим его позже) по запуску файла /home/svnmirror/svnmirror.up.sh 

22      2       *       *       *       svnserve        /home/svnmirror/svnmirror.up.sh

Дописываем в файл /etc/rc.conf строки:

svnserve_enable="YES"
svnserve_flags="-d -R --listen-host 0.0.0.0"
svnserve_data="/home/svnmirror"
svnserve_user="svnserve"
svnserve_group="svnserve"

Запускаем svnserve как указано ниже или перезагружаем сервер ))) :

# /usr/local/bin/svnserve -d -R --listen-host 0.0.0.0  -r /home/svnmirror

Всё.

 

Можно обновляться со своего локального svn зеркала. Однако нас ждёт засада, если мы уже обновлялись до этого с другого svn'а. Оно скажет так:

svn: E155000: '/usr/ports' is already a working copy for a different URL

Есть команда по смене адреса у нужного репозитория. Выглядит так: svn relocate svn://YOUR-HOST/ports/head /usr/ports Но у меня она не сработала. Вернее, она молча выполнилась. А при попытке потом обновиться через команду уже со своего mirror'а svn co svn://YOUR-HOST/ports/head /usr/ports оно пишет кучу строк в таком стиле Skipped 'comms' -- Node remains in conflict. Выход из этой ситуации - удалить папку .svn.

Как прочекать диск удалённой системы

Иногда бывает после сбоя питания (UPS умер или ещё что) на диске UFS появляются ошибки и fsck не может их исправить.

Ехать к серверу неудобно или далеко.
Рук поблизости для входа в singlemode нет.

WARNING!!. На системе FreeBSD 10.3-STABLE (KMD) #0 r302767M и без gmirror последний пункт (reboot) выполнился без проблем и система поднялась
На системе 9.3-STABLE FreeBSD 9.3-STABLE #0 r292093 с gmirror последний пункт не выполнился, система зависла в panic и пришлось нажимать reset, в итоге при загрузке оно снова начало проверять диск.
Требуется проводить 
ещё тесты.

 

 1. В файле /etc/fstab прописываем флаг монтирования файловой системы в ro, вместо положенных rw

# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/mirror/gm0p2       /               ufs     ro      1       1
/dev/mirror/gm0p3       none            swap    sw      0       0
md              /tmp            mfs     rw,-s1024m      2       0
md              /var/tmp        mfs     rw,-s1024m      2       0

2. В файле /etc/rc.conf отключаем все значимые сервисы, типа mysql, apache.

#apache24_enable="YES"
#mysql_enable="YES"

3. Останавливаем все значимые сервисы. Не знаю, остановит ли система mysql и apache сама, если в rc.conf они не включены.

/usr/local/etc/rc.d/apache24 stop
/usr/local/etc/rc.d/mysql-server stop

4. reboot.

5. Запускаем fsck -y

6. Монтируем файловую систему на запись.

mount -w /

7. Редактируем обратно файл /etc/fstab 

# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/mirror/gm0p2       /               ufs     rw      1       1
/dev/mirror/gm0p3       none            swap    sw      0       0
md              /tmp            mfs     rw,-s1024m      2       0
md              /var/tmp        mfs     rw,-s1024m      2       0

8. Редактируем обратно /etc/rc.conf, включая все значимые сервисы, типа mysql, apache.

apache24_enable="YES"
mysql_enable="YES"

9. reboot.

PS. На системе FreeBSD 10.3-STABLE (KMD) #0 r302767M 9ый пункт выполнился без проблем, система перезагрузилась и вернулась в онлайн.
На системе 9.3-STABLE FreeBSD 9.3-STABLE #0 r292093 случился panic и пришлось делать reset, после чего проверка диска пошла по новой.

 

Сокращение расходов на домены в nic.ru (он же РУ-Центр)

Как знают все, кого это касается ))) А именно касается регистрации доменов.

Так вот как знают в узких кругах, nic.ru, он же ru-center придумал новую обоссаку по отмене партнёрских скидок и запуск мегакрутой клубной программы. Это когда тебе нужно платить не за домены, а за право быть клубным перцем. При чём за это тебе даётся скидка на домены. Ясное дело, что для хотя бы окупания этой мегакрутой задумки нужно регистрировать домены сотнями. А если у тебя их пара десятков, ну ладно, пара сотен, то ты пролетаешь как фанера над Парижем. Хотя я не знаю как это - не видел.

К слову сказать в своё время я продлял свои пару сотен доменов по 600 рублей несколько лет. РУ-Центр неплохо на этом обогатился, про партнёрку мне ясное дело никто ничего не говорил. А зачем?! Клиент платит, мы молчим. Мы довольны, на клиента посрать. Поэтому я считаю, что эти граждане те ещё говнюки.

Выход такой:

Описан подробно здесь, а сюда его скопирую на всякий случай.

 

Регистратор RU-CENTER (NIC.RU), продление доменов по 125 рублей


Для проведения каких-либо действий над Вашими доменами Вам нужно:

  1. В своем личном кабинете, на сайте nic.ru, передать свою анкету под управление партнера 11111 (11111/NIC-REG). Если Ваша анкета уже находится под управлением, то этот пункт меню будет называться «Сменить партнера»;
  2. Зарегистрироваться в биллинге my.ru-tld.ru
  3. В биллинге, в разделе «Товары/Услуги» – «Доменные имена» нужно произвести импорт доменов. Для этого в верхнем правом углу нажимаем «Импорт»;, вписываем номер своей анкеты в Ру-центре и пароль от неё;
  4. Через 1-10 минут список Ваших доменов появится в биллинговой системе, и Вы сможете продлевать домены.

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

Вы можете из нашей биллинг-системы продлевать домены, регистрировать новые домены на свою анкету, менять NS-сервера.

Лечим modX сообщение "Каталог ядра в открытом доступе".

Лечим modX сообщение "Каталог ядра в открытом доступе".

Для этого переносим директорию /core за пределы публичной части сайта.

Официальная инструкция почему-то стала немного не соответствовать действительности.

В файле core/config/config.inc.php редактируем две переменные: $modx_core_path и $modx_processors_path, а не одну как написано в официальной инструкции.

Редактируем файл /config.core.php

Редактируем файл /connectors/config.core.php

Редактируем файл /manager/config.core.php

Таблицу modx_workspaces в mysql редактировать не нужно, потому что там прописано {core_path}, а не какой-либо реальный путь.

Очищаем директорию core/cache иначе не откроется админка.

Вуаля.