Blog of Khlebalin Dmitriy

(Записки из мира IT…)

Аварийное восстановление сервера Exchange 2010.

В рамках грядущего проекта по внедрению Exchange 2010, постепенно ознакамливаюсь с нюансами внедрения. Заранее решил посмотреть в инете, как осуществляется процесс восстановления сервера.

САМ НЕ ПРОБОВАЛ  ВОССТАНАВЛИВАТЬ EXCHNGE 2010 (ПРОБОВАЛ ТОЛЬКО 2003Й), БОГ ДАСТ НЕ ПОПРОБУЮ, И ВАМ НЕ РЕКОМЕНДУЮ СТОЛКНУТЬСЯ С ЭТИМ.

Но для информации знать будет полезно. Наткнулся на интересную статью. К сожалению автор неизвестен (а жаль). Итак собственно к теме статьи.

Как правило, после успешной установки и настройки сервера, следующее, о чем задумывается системный администратор – это о том, как он его будет восстанавливать в случае аварии. В этой статье мы поговори о том, как можно восстановить полностью вышедший из строя Exchange Server 2010.

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

Удалены группы хранения (Storage Groups)
Exchange 2010 теперь не содержит группы хранения, которые использовались в Exchange 2007 для поддержания логических групп баз данных и организации сценариев высокой доступности.

Введеныбазыданныхвосстановления (Recovery Database)
На замену Recovery Storage Groups пришли Recovery Databases (RDB ). Теперь, если у вас возникает необходимость в восстановлении как целых почтовых ящиков, так и отдельных писем, вам нужно использовать базы данных восстановления (RDB ).

Возросло количество поддерживаемых баз 
К каждому серверу Exchange 2010 Enterprise теперь может быть одновременно подключено до 100 баз данных почтовых ящиков (вместо 50-и в Exchange 2007) и до 5 баз к Exchange 2010 Standard. При этом, данное ограничение не касается общего числа объектов баз данных, хранящихся в Active Directory Domain Services (AD DS).
На каждом сервере, в одно время, может быть смонтирована только одна база данных восстановления, плюсом к 100, либо 5-и уже имеющимся.

Добавлены группы высокой доступности (Database Availability Groups)
С выходом Exchange 2010, Microsoft улучшила функции CCR и SCR, соединив две функции в одном компоненте DAG (Database Availability Group), DAG стала новой функцией непрерывной доступности баз данных почтовых ящиков. Группы DAG обеспечивают защиту на уровне базы, сервера и узла и делают развертывание решения высокой доступности и аварийного восстановления на уровне сайта гораздо проще, нежели в предыдущих версиях Exchange. Подробнее тут — http://itband.ru/2010/04/exchange-2010-dag-nlb/

Не поддерживается SIS
В Exchange2010 разработчики отказались от механизмов SIS.
SIS (Single Instance Storage) — технология хранилищ Microsoft Exchange Server (v4.0 – 2007), позволяющая содержать в почтовой базе письмо и вложения в единственном экземпляре, независимо от количества отправителей и получателей этого письма, чьи почтовые ящики также располагаются в этой базе данных. Подробнее тут — http://itband.ru/2010/04/exchange-2010-sis/.

Настройки баз данных перенесены на уровень организации
Изменились PowerShell команды по управлению хранилищем
Подробнее можно прочитать в стать Determining Exchange Server 2010 Storage Configuration (http://msdn.microsoft.com/en-us/library/bb204051.aspx)

Теперь о восстановлении сервера после аварии
Исходя из всего выше сказанного, несколько изменился и сам подход к резервному копированию и восстановлению серверов Exchange 2010. На мой взгляд, наиболее оптимальным и надежным способом обеспечения высокой доступности баз данных почтовых ящиков в Exchange 2010 является использование функционала DAG (Database Availability Group). Но если у вас нет возможности использовать DAG в организации, то, по большому счету, кроме использование встроенной в Windows Server системы архивации Windows Server Backup, у вас нет механизмов обеспечения надежности Echange Server`a (самостоятельные решения вроде Data Protection Manger и т.п. в расчет не берем).
Примечание: Использование групп высокой доступности не избавляет вас от необходимости выполнять резервное копирование серверов и баз данных. 
Microsoft Exchange Server 2010 включает в себя подключаемый модуль системы архивации данных Windows Server, который позволяет создавать архивы данных Exchange на основе службы теневого копирования томов (VSS). Именно про восстановление сервера из такого архива мы и поговорим далее.

От теории к практике
Для примера, рассмотрим ситуацию, когда у вас был Exchange Server 2010, на котором в одной базе MDB хранилась вся почта пользователей:

В один «прекрасный» момент сервер вышел из строя, и у вас осталась только копия базы данных почтовых ящиков, сохраненная на другом сервере в сетевой папке. Восстановление сервера дело достаточно не быстрое и хлопотное, особенно, если вы занимаетесь этим раз в 3 года и отработанных навыков у вас нет, так что первое, что вам нужно сделать – это обеспечить пользователей возможностью отправлять и получать почту при помощи функциипереносимости аварийного восстановления (Dial Tone Portability), а потом уже можно не спеша приняться за восстановление их старых писем.

Примечание:Переносимости аварийного восстановления (Dial Tone Portability) — это функция Microsoft Exchange Server 2010, которая обеспечивает решение для ограниченной поддержки непрерывной работы электронной почты. Переносимость аварийного восстановления предоставляет пользователю временный почтовый ящик для отправки и получения электронной почты на время восстановления или исправления его исходного почтового ящика. Временный почтовый ящик может находиться на том же сервере почтовых ящиков Exchange 2010 или на любом другом сервере почтовых ящиков Exchange 2010 в организации. Это позволяет разместить на дополнительном сервере пользовательские почтовые ящики, располагавшиеся на сервере, который стал недоступен. Клиенты, поддерживающие функцию автообнаружения, например Microsoft Office Outlook 2003/2007/2010, автоматически перенаправляются на новый сервер без необходимости вручную обновлять профиль настольной системы пользователя.

Составим примерный план действий:
1. Взять уже имеющийся, либо установить временный сервер Exchange 2010 (2) c ролью MailBox.
2. Создать аварийную базу данных (Dial Tone Database) и перенастроить почтовые ящики на работу с ней.
3. Переустановить старый сервер при помощи команды Setup /m:RecoverServer — Exchange 2010 (3)
4. Восстановить файлы базы данных почтовых ящиков из резервной копии на восстановленный сервер в базу данных MDB2.
5. Переключить пользователей с аварийной базы данных на восстановленную MDB2.
6. Отключить базу DialTone и создать из неёбазу данных восстановления RecDB.
7. Скопировать содержимое RecDB в активную базу данных MDB2.
8. Можно отключать Exchange 2010 (2).

Поговорим о каждом шаге подробнее:
Примечание: Не нужно забывать, что аварийная база данных и база данных восстановления (RDB), это разные вещи, соответственно, если на последнюю ограничение по количеству поддерживаемых баз данных сервером не накладывается (100 или 5), то для создания аварийной базы данных количество развернутых баз данных не должно превышать установленное максимальное количество.
Использование графической консоли управления Exchange при работе с базами данных поддерживается плохо, поэтому все действия будем выполнять из командной консоли.

Создаем аварийную базу:
a. Создаем пустую аварийную базуDialTone командлетом New-MailboxDatabase:

New-MailboxDatabase -Name DialTone –Server Server2 –EdbFilePath E:\Dialtone\DialTone.EDB –LogFolderPath E:\Dialtone\

b. Используем командлет Set-Mailbox для переключения почтовых ящиков пользователей, на аварийную базу DialTone:

Get-Mailbox -Database MDB | Set-Mailbox -Database DialTone

c. Монтируем базу данных DialTone при помощи команды Mount-Database, либо из графической консоли управления:

Mount-Database -Identity DialTone

После переключения пользователей на аварийную базу данных, MS Outlook, с включенным кэшированием, выдаст следующее сообщение:

Фактически, произошло следующее – Outlook «понял», что произошло переключение на другую базу данных, и сохранил OST файл с кэшем старых писем. Теперь он предлагает выбор между работой с новой базой данных в режиме on-line, либо просмотр старых писем из кэша в режиме off-line. Это очень правильное решение, но у него есть один большой минус, о котором мы поговорим в конце.

Восстановление старого сервера
Дело в том, что очень большая часть настроек MS Exchange хранится в Active Directory, в связи с этим, можно переустановить сервер Exchange, автоматически применив эти настройки. Для этого нужно:

  • Сбросить учетную запись сервера в AD, выбрав пункт меню Переустановить учетную запись (Reset Account);
  • Установить операционную систему на новое железо;
  • Назначить серверу такое же имя, какое было до аварии;
  • Ввести сервер в домен;
  • Установить необходимые компоненты ОС;
  • Запустить установку сервера с параметром Setup /m:RecoverServer;

  • Проверить все дополнительные настройки.

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

  • Восстановить файлы и журналы базы данных почтовых ящиков из архива в альтернативное расположение — E:\Recovery\ на восстановленном сервере;

  • Создать базу данных командлетом New-MailboxDatabase и указать, где лежат восстановленные из архива файлы базы данных почтовых ящиков:

New-MailboxDatabase -Name MDB2 -Server Server3 -EdbFilePath «E:\Recovery\DB_MDB\MDB.EDB» -LogFolderPath «E:\Recovery \LOG_MDB»

  • Монтируем базу данных

Mount-Database “MDB2”

  • Переключаем обратно пользователей на восстановленную базу данных:
Get-Mailbox -Database DialTone | Set-Mailbox -Database
В результате переключения, на какое-то время было приостановлено обслуживание пользователей и Outlook Web App выдал сообщение о том, что происходит перемещение почтовых ящиков:

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

Объединение баз DialToneи MDB2

Следующим этапом будет объединение содержимого базы данных DialTone с восстановленной базой. Это сделать необходимо, т.к. в базе DialTone находятся письма, полученные за время проведения аварийного восстановления.
Для объединения двух баз воспользуемся базой данных восстановления (Recovery Database).
Примечание: База данных восстановления является особой разновидностью базы данных почтовых ящиков, её нужно использовать для подключения базы почтовых ящиков, с целью извлечения из неё данных. С помощью баз данных восстановления можно восстановить данные из архива или копии базы данных без нарушения доступа пользователей к текущим данным. 
Необходимо выполнить следующие действия:

  • Отключить базу данных DialTone
  • Создать базу данных восстановления RecDB (Recovery Database) командлетом New-MailboxDatabase с параметром –Recovery и указать, где лежат файлы базы DialTone:

New-MailboxDatabase -Recovery -Name RecDB –Server Server2 –EdbFilePath E:\Dialtone\DialTone.EDB –LogFolderPath E:\Dialtone\

  • Необходимо убедится, что полученная база данных находиться в состоянии чистого отключения (clean shutdown). Поскольку база данных восстановления представляет собой альтернативное расположение восстановления для всех баз данных, все восстановленные базы данных будут находиться в состоянии неправильного отключения (dirty shutdown). Для проверки перейдем в папку с базой и запустим команду

Eseutil.exe /MH “DialTone.EDB”

Для переключения базы данных в состояние clean shutdown нужно выполнить операцию Recovery в каталоге с лог-файлами базы данных при помощи утилиты Eseutil:

Eseutil /R E00 /I /d

Но данная команда часто выдает ошибку, поэтому, можно использовать вместо Recovery операциюRePair в каталоге с файлами базы (edB ):

Eseutil /P “ DialTone.EDB”

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

Mount-Database “RecDB”

  • Следующим этапом будет восстановление писем из Recovery Database в активную базу данных. Для извлечения данных из RDB нужно воспользоваться командлетом Restore-Mailbox:

Для переноса содержимого всех почтовых ящиков из базы данных восстановления RecDB воспользуемся следующей конструкцией:

Get-Mailbox –Database MDB2 | Restore-Mailbox -RecoveryDatabase RecDB

Также, Recovery Database можно использовать для восстановления конкретных почтовых ящиков и даже отдельных писем, как в «родное» место расположения, так и в альтернативный ящик:
В этом примере содержимое почтового ящика пользователя User1 восстанавливается в папку «Recovery» почтового ящика пользователяAdmin.

Restore-Mailbox -Identity Admin -RecoveryDatabase RecDB -RecoveryMailbox User1 -TargetFolder Recovery

В данном примере восстанавливаются только сообщения электронной почты, удовлетворяющие следующим условиям:

  • Строка темы содержится слово «Meeting».
  • Тело сообщения содержит фразу «Halo 3».
  • Сообщение находится в папке «Входящие» или «Календарь».

Restore-Mailbox -Identity Admin -RecoveryDatabase RecDB -SubjectKeywords «Meeting» -ContentKeywords «Halo 3» -IncludeFolders \Inbox,\Calendar

  • Далее, можно посмотреть статистику баз данных (сравнить, что было и что стало) командой

Get-MailboxStatistics -Database “RecDB”

Get-MailboxStatistics -Database “MDB2”

В результате проделанных выше манипуляций, в базу данных MDB2 должны быть восстановлены письма, полученные за время проведения аварийных работ на сервере Exchange.

НастройкаMS Outlook послеDial-Tone Database restore.

В заключение расскажу про обещанный минус использования метода переносимости аварийного восстановления (Dial Tone Portability)для предоставления временного доступа к почтовым ящикам пользователей. Дело в том, что как говорилось выше, Outlook «понимает», что произошло переключение почтового ящика на другую базу данных, и сохранив старый OST-файл, при каждом запуске предлагает выбор между его просмотром и работой с новым OST-файлом и соответственно с новой базой данных. Удалить этот самый кэш можно двумя способами:

В локальных настройках Outlook 2010:
1. Заходим в свойства учетной записи -> Другие настройки;
2. Открываем вкладку Дополнительно;
3. Убираем галочку Использовать режим кэширования Exchange;
4. Нажимаем кнопку Применить, на что Outlook говорит, что для вступления изменений в силу необходимо перезапустить программу, но сейчас перезапускать его мы не будем;
5. Нажмем кнопку Настройка файла данных Outlook;
6. Нажмем кнопку Не использовать — тем самым удалим кэш;
7. Далее ОК;
8. Теперь снова можно поставить галку напротив Использовать режим кэширования Exchange;
9. Перезапускаем Outlook и видим, что назойливое сообщение исчезло.

Отключить/включить кэширующий режим для всех можно чрез GPO, как написано в статье на TechNet`e  -http://technet.microsoft.com/en-us/library/cc179175.aspx

Заключение

Я попытался описать наиболее общий пример восстановления сервера после аварии. Ещё раз повторю, если у вас есть возможность использовать группы доступности DAG, то непременно сделайте это, DAG очень сильно облегчит вам жизнь и сомневаюсь, что все описанное выше вам вообще потребуется.
Также прошу учесть, что все манипуляции были проделаны лишь в тестовой среде, так что как пойдет процесс восстановления в реальных условиях зависит от многих факторов, которые трудно предугадать.

Всем удачной работы!!!

 

30.06.2011 Posted by | ms exchange 2010 | Комментарии к записи Аварийное восстановление сервера Exchange 2010. отключены

Автоматически забираем файлы с FTP сервера.

Некоторое время назад,  в некоторых филиалах нашей компании появилась необходимость забирать определенный файл с нашего FTP сервера в Москве и класть их себе в определенную папку. Реализовать это можно двумя путями:

— Написать VBA скрипт и прикрутить его к шедулеру;

— Написать BAT файл и прикрутить его к шедулеру;

Так как писатель скриптов из меня никакой (я конечно могу написать, но достаточно простенькие скрипты на VBA), я пришел к выводу, что предпочтительней для меня будет накидать батник. Итак вот что у меня получилось, создаем батник (например transfer.bat) вот с таким текстом:

@Echo Off
:: ~Параметры соединения
Set $FTP=192.168.0.xxx (или ваш IP фтп сервера)
Set $User=password ##(или ваш пользователь заведенный на фтп сервере)
Set $Pass=password  ##(или ваш пароль заведенный для этого пользователя на фтп сервере)

:: ~Файл и пути копирования

SET $PATH=/OUT/Caterpillar
SET $FILE=filename.dat
SET $BIN=binary
SET $DOWN=c:\temp\filename.dat

:: ~Временный файл
Set $FFtp=%~dpn0.tmp
:: Собираем TMP-файл
Echo %$User%>»%$FFtp%»
Echo %$Pass%>>»%$FFtp%»
Echo %$BIN%>>»%$FFtp%»
Echo cd «%$PATH%»>>»%$FFtp%»
Echo get «%$FILE%» «%$DOWN%»>>»%$FFtp%»
Echo bye>>»%$FFtp%»
:: Запуск
FTP -s:»%$FFtp%» %$FTP%

Далее прикручиваем данный батник к встроенному в винду шедулеру в нужное нам время, и наслаждаемся….

Всем удачной работы !!!

 

29.06.2011 Posted by | scripts | Комментарии к записи Автоматически забираем файлы с FTP сервера. отключены

Web-сервер (FreeBSD + Apache2 + PHP +MySQL + ProDTPd + SVN + Trac) (часть 3).

Пришло время продолжить начатое здесь

https://khlebalin.wordpress.com/category/linux-and-unix/

 

Установка PhpMyAdmin

Для более удобной работы с MySQL сервером ставим PhpMyAdmin. Ставится он следующим образом:

cd /usr/ports/databases/phpmyadmin && make install clean && rehash

В появившемся диалоге оставляем все по умолчанию. После установки начинаем его немного настраивать.

Для начала перенесем рабочую директорию PhpMyAdmin из /usr/local/www в /usr/web:

mv /usr/local/www/phpMyAdmin /usr/web/

Далее создадим директорию conf

mkdir /usr/local/etc/apache22/conf

В нее поместим pma.conf со следующим содержанием:

Alias /phpmyadmin/ «/usr/web/phpMyAdmin/»

<Directory «/usr/web/phpMyAdmin/»>

Options none

AllowOverride Limit

Order Allow,Deny

Allow from all

Deny from none

</Directory>

И добавим в самый конец httpd.conf следующую строку:

Include etc/apache22/conf/*.conf

Далее идем по адресу http://ip_tachki/phpmyadmin/index.php и смотрим результат. Вводим логин root и пароль MySQL и попадаем в сам PhpMyAdmin.

Далее настраиваем PhpMyAdmin. Идем в /usr/web/phpMyAdmin, находим там config.inc.php и дописываем в него следующие строки:

$cfg[‘LeftFrameLight’] = true;

$cfg[‘LeftFrameDBTree’] = true;

$cfg[‘LeftFrameDBSeparator’] = ‘_’;

$cfg[‘LeftFrameTableSeparator’] = ‘__’;

$cfg[‘LeftFrameTableLevel’] = 1;

$cfg[‘LeftDisplayLogo’] = false;

$cfg[‘LeftDisplayServers’] = false;

$cfg[‘LeftPointerEnable’] = true;

$cfg[‘blowfish_secret’] = ‘test’;

В итоге я увидел следующую картинку:

Черт… Снова траблешутинг.

Немного покрутил файлы. Получил уже вот такое окно но все равно пока без результатно.

На всякий случай решил еще раз проверить, что сервер запущен:

Добавил в этот файл config.inc.php некие строки:

$i=0;
$i++;
$cfg[‘Servers’][$i][‘user’] = ‘root’;
$cfg[‘Servers’][$i][‘password’] = ‘mypassword’; // use here your password

Ребутнул сервак, но положительного результата это не принесло, появилось другое окно:

Копаю дальше: очистил кэш браузера все пропало но в базу все равно не пускает. Буду думать.

Установка ProFTPd

Устанавливаем:

cd /usr/ports/ftp/proftpd-mysql && make install clean && rehash

В появившемся диалоге выбираем:

  • MySQL
  • Quota
  • Ratio
  • Rewrite
  • Wrap

По окончании установки рихтуем proftpd.conf до такого состояния:

ServerName              «DEV.LOCAL FTP Server»

ServerType              standalone
DefaultServer           on
ServerAdmin             root@dev.local
Port                    21
Umask                   022
MaxInstances            30
User                    ftp
Group                   ftp
SQLAuthTypes            Plaintext
SQLAuthenticate         users
SQLConnectInfo          DB_NAME@localhost:3306 USER PASSWORD
SQLUserInfo             `users_table` `username` `password` `uid` `gid` \
                        `homedir` `shell`
RequireValidShell off
SQLLogFile      /var/log/proftpd.log
SQLLog          PASS            counter_login
SQLNamedQuery   counter_login   UPDATE "`last_login`=UNIX_TIMESTAMP(), \
                                `login_count`=`login_count`+1 WHERE \
                                `username`='%u'" `users_table`
SQLLog          ERR_PASS        counter_err
SQLNamedQuery   counter_err     UPDATE "`last_err_login`=UNIX_TIMESTAMP(), \
                                `err_login_count`=`err_login_count`+1 WHERE \
                                `username`='%U'" `users_table`
SQLLog          RETR,STOR               log_story_transfer
SQLNamedQuery   log_story_transfer      INSERT "'',\
                                        UNIX_TIMESTAMP(),'%u',\
                                        '%f', '%b', '%h', \
                                        '%a', '%m', '%T'" \
                                         `xfer_table`
SQLLOG          ERR_RETR,ERR_STOR,ERR_DELE,ERR_RMD,ERR_RNTO\
                                        log_err_modify
SQLNamedQuery   log_err_modify          INSERT "'',\
                                        UNIX_TIMESTAMP(),\
                                        '%u', '%f', '%h', \
                                        '%a', '%m'" `xfer_errors`
 
UseReverseDNS     off
IdentLookups      off
 
 
 
DefaultRoot            ~
 
<Directory ~>
AllowOverwrite          on
<Limit Write>
AllowAll
</Limit>
<Limit READ>
AllowAll
</Limit>
</Directory>
 
 
<Anonymous /usr/home/ftp>
User            ftp
Group           ftp
UserAlias       anonymous ftp
MaxClients      10      "Sorry, max %m users - try again later"
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>

Далее идем в PhpMyAdmin, создаем в нем базу ftp и добавляем следующие таблицы и значения:

CREATE TABLE `users_table` (

  `unic_id` int(11) NOT NULL auto_increment,
  `username` varchar(20) NOT NULL,
  `password` varchar(20) NOT NULL,
  `groupname` varchar(24) NOT NULL,
  `uid` int(11) NOT NULL,
  `gid` int(11) NOT NULL,
  `homedir` varchar(50) NOT NULL,
  `shell` varchar(20) NOT NULL,
  `last_login` int(15) NOT NULL,
  `login_count` int(15) NOT NULL,
  `last_err_login` int(15) NOT NULL,
  `err_login_count` int(15) NOT NULL,
  PRIMARY KEY  (`unic_id`)
) ENGINE=MyISAM COMMENT='Таблица пользователей';
INSERT INTO `users_table` VALUES (1,'admin','123','admin',
1001,1001,'/usr/web','/sbin/nologin',0,0,0,0);
CREATE TABLE `xfer_errors` (
  `unic_id` int(32) NOT NULL auto_increment,
  `timestamp` int(15) NOT NULL,
  `user_name` varchar(64) NOT NULL,
  `file_and_path` tinytext NOT NULL,
  `client_name` varchar(127) NOT NULL,
  `client_IP` varchar(15) NOT NULL,
  `client_command` varchar(5) NOT NULL,
  PRIMARY KEY  (`unic_id`)
) ENGINE=MyISAM COMMENT='Таблица ошибок при работе';
CREATE TABLE `xfer_table` (
  `unic_id` int(32) NOT NULL auto_increment,
  `timestamp` int(15) NOT NULL,
  `user_name` varchar(64) NOT NULL,
  `file_and_path` tinytext NOT NULL,
  `bytes` int(15) NOT NULL default '0',
  `client_name` varchar(127) NOT NULL,
  `client_IP` varchar(15) NOT NULL,
  `client_command` varchar(5) NOT NULL,
  `send_time` varchar(9) NOT NULL default '0',
  PRIMARY KEY  (`unic_id`)
) ENGINE=MyISAM COMMENT='Таблица, чё приняли-передали';

Заводим в системе пользователя `ftp` командой `adduser`, после чего создаём файло для логов и даём на него права:

touch /var/log/proftpd.log

chown ftp:wheel /var/log/proftpd.log

Выставляем права на каталог ftp:

chown ftp:ftp /usr/web/ftp

Добавляем proftpd в автозагрузку и запускаем

echo ‘proftpd_enable=»YES»‘ >> /etc/rc.conf

service proftpd start

И проверяем работу, заходим на сервер от анонимуса и от пользователя админ.

P.S. Как выдергивать данные из MySQL для статистики – разберетесь сами…

Продолжение следует…

Всем удачи!!!

28.06.2011 Posted by | linux and unix | Комментарии к записи Web-сервер (FreeBSD + Apache2 + PHP +MySQL + ProDTPd + SVN + Trac) (часть 3). отключены