Достаточно неплохой ресурс по Project Server:
 http://www.pmprofy.ru/default.asp 

В моем примере использовалась FreeBSD версии 5.3, Putty 0.58.

Заходим на FreeBSD шелл под пользовательским аккаунтом, т.е. не делаем ни SU ни SUDO.
Запускаем:
ssh-keygen -t dsa
после чего нас спросят пароль (тот же что и для входа), и место сохранения ключей, по умолчанию все будет в ~/.ssh/id_dsa и ~/.ssh/id_dsa.pub.
Первый ключ id_dsa приватный, его нам следует забрать и тут же удалить с сервера, второй ключ id_dsa.pub публичный, он будет использоваться на сервере для аутентификации пользователя.

cat id_dsa.pub>authorized_keys # копируем ключ в ключи для авторизации
rm id_dsa.pub # удаляем ненужный public

id_dsa копируем к себе на рабочую станцию (в моем случае Windows XP), запускаем puttygen.exe из состава Putty, загружаем этот ключ и сохраняем в формате putty (тот что ppk).

Запускаем pageant.exe который повиснет в трей и будет держать все наши ключи для авторизации, добавляем туда наш ключ (у меня это в винде в автозагрузке, передается параметром имя файла с ключем).

В самом Putty в конфигурации хоста указываем юзернейм и putty key -> наш ключ, не забываем сохранить.

И у вас должно все работать. 

Понятное дело, что в "проводнике" мы удаленные папки не увидим, и тем не менее шары на них виртуально присутствуют.

Проверим командой
net share
которая нам покашет список шар, к примеру:
BackupMedia  D:\BackupMedia

самого каталога нет, но удалить шару мы хотим, для этого выполним команду

net share BackupMedia \DELETE

которая и удалит требуемую шару. 

Источник: FreeBSD роутер, снимаем статистику при помощи netgraph, отправляем на другой хост используя протокол netflow.

Анализ структуры трафика и графическое отображение делаем при помощи ManagEngine Netflow Analyzer 4.

Очень красиво так получается :)


ngctl connect fxp0: fxp0:lower upper right
ngctl mkpeer fxp0:lower netflow left2right iface0
ngctl name fxp0:lower.left2right netflow
ngctl msg netflow: setifindex { iface=0 index=4 }
ngctl mkpeer netflow: ksocket export inet/dgram/udp
ngctl msg netflow:export connect inet/192.168.0.12:9996

Где на 192.168.0.12 слушает Netflow Analyzer. 

http://www.unixfaq.ru/index.pl?req=qs&id=247 

Антивирь произвел очень приятное впечатление, установлен был вместо GFI Security к которому доверия нет после простоя почтовой системы и потери корреспонденции вследствии ошибки в обновлении.

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

Однозначно рекомендед фор корпорейт юз.

 

Соответственно zebra, с ее OSPF и BGP до одного места
Это факт, который заставляет меня обратиться к использованию Linux.

  читать далее >>

Т.к. этот вопрос был задан не единожды, то запишу инструкии по входу в админзону Project Server.

Попробуйте вход с адреса:
http://project/projectserver/Admin/Admin.asp

а также вход с комбинациями "Administrator", "Администратор" и
"DOMAINNAME\superuseraccountname",

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

-----------------------------------------------------------------------
Вот ответ одной из читательниц:
-----------------------------------------------------------------------
Вход на сервер успешно выполнен и даже добавлены уже новые пользователи для Project'а.
Сама процедура первой регистрации происходила следующим образом:

- в качестве логина был набран "Администратор" - затем введен пароль администратора,созданный при установке Project Server
- далее было прочитано предоставленное лиц. соглашение
- установлена галочка, что мол соглашение принимаю, и нажатие кнопки Next
- и безмерная радость, что вход на сервер все-таки выполнен и теперь можно с ним работать. Спасибо за помощь. 

 

На самом деле этот вопрос можно разделить на две задачи. Первая, использование второго канала в качестве резервного, т.е. такого что бы поднимался в случае падения основного. Вторая задача - разгрузить первый канал, запустить часть некритичного трафика через второй канал. По схеме 2 уменя работает http трафик, т.е. на второй канал направляется весь http трафик, который и является, в общем, основным "грузилом", которое отражается на терминальных пользователях работающих на том же канале. Разруливается это путем принудительного кеширования и перенаправления squidом на тот канал, на который нужно. Из нюансов: POST запросы через кеш не рулят через резервный канал, подменяем в сквиде исходящий IP.

Ну это я отвлекся, хотел рассказать о способе организации failover резервного канала.
Т.к. во FreeBSD почему-то до сих пор отсутствует реализация multiroute и мы не можем задать два default гейтвея, то о "стандарном" способе речь не идет.
Наиболее оптимальным видится выход: стоит второй маршрутизатор рядом в той же сети, натроенный на второй канал, возможно с поднятым VPN, при падении первого канала на основном маршрутизаторе просто заменяем default route на адрес второго маршрутизатора, и алга.

А если два маршрутизатора это расточительно, то для экономии мы можем воспользоваться "виртуальными машинами", кто знает, что у нас для этого есть во фре?

Ну это все мысли, попробую на практике и отпишу тут же.

 

Вот средство для разметки дисков в Debian Linux

А местный формат - mkfs