Собственно там ничего сложного, особенно если стоит линуксовый установщик yum. Если его естественно нет, то делаем все по старинке:
$ mkdir /usr/local/yum
$ cd /usr/local/yum
$ wget http://linux.duke.edu/projects/yum/download/2.0/yum-2.0.7.tar.gz
$ tar xvzf yum-2.0.7.tar.gz
$ cd yum-2.0.7
$ ./configure
$ make && make install
после чего продолжаем будто yum у нас уже стоял:
$ yum install mysql
$ yum install mysql-server
$ yum install mysql-devel
$ chgrp -R mysql /var/lib/mysql
$ chmod -R 770 /var/lib/mysql
$ service mysqld start
После этого загоняем мускуль в автозагрузку:
$ chkconfig mysqld on && service mysqld restart && chkconfig –list | grep mysqld
После этого задаем пароль для рутового пользователя сервера баз данных:
/usr/bin/mysqladmin -u root password ‘Password’
Затем переходим к созданию необходимой базы данных и пользователя:
$  mysql -u root -p
mysql> CREATE DATABASE ИмяБазы;
mysql> USE  ИмяБазы;
mysql> GRANT ALL PRIVILEGES ON *.* TO Юзер@localhost  IDENTIFIED BY ‘ПАРОЛЬ’ WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;
mysql> \q

После чего можно радоваться тому факту что на нашем дешевом VPS теперь крутится движок баз данных mySQL.

Для начала понимаем что это вообще за класс операционки, путем вывода универсальной для всех Unix-систем команды:
$ uname -a
которая нам выведет что то типо такого:
Linux hostname.com 2.6.18-194.17.4.el5PAE #1 SMP Mon Oct 25 16:35:27 EDT 2010 i686 i686 i386 GNU/Linux
или
FreeBSD hostname.com 5.5-STABLE FreeBSD 5.5-STABLE #0: Wed Dec  5 20:00:38 MSK 2007  email@hostname.com:/usr/obj/usr/src/sys/GENERIC  i386
или
AIX svcas07 3 4 000145364C00
OS Name Release Version Machine ID
из чего нам либо станет понятно кто это, либо перейдем к более подробному изучению линуха, для того чтобы уже конкретно определить версию линукса:
$ cat /proc/version
Linux version 2.6.18-194.17.4.el5PAE (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Oct 25 16:35:27 EDT 2010
то есть нам понятно семейство линуха и версия ядра, тем более что у семейства шапки есть более подробная команда, для того чтобы узнать версию linux:
$ cat /etc/redhat-release
CentOS release 5.6 (Final)
По хорошему это исчерпывающий ответ, но в шапке также имеется дополнительная утилита ставящаяся в полном комплекте, которая выведет более подробную информацию про версию linux:
$ lsb_release -a
LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description:    CentOS release 5.5 (Final)
Release:        5.5
Codename:       Final

Но что же тогда имеется ввиду? А в этой справочке- есть такие строки- внедрение свободного ПО, то есть получается эти самые 3 миллиарда долларов выделяются на внедрение и разработку документации под это внедрение. Вот тебе и распил. Никто ничего не будет писать или создавать- занесут небольшую денежку GNU за коммерческое использование свободных продуктов и далее “Ланит”, или кто нить еще из сидящих на госзаказе, будет осваивать вышеупомянутые бабуськи на просторах бескрайней.

А что же, спрашивается, относительно национальной ОС? Все бы ничего, но со слов директора GNU/Linux-центра Павла Фролова, людей способных реализовать подобный проект, в стране от силы 50 человек, не объединенных между собой ничем. Поэтому наиболее правильным путем разработки было бы собрать их всех вместе и запереть на год-другой в каком нибудь помещении, по аналогии с закрытыми КБ советских времен. А пока эти люди разъединены, то и разрабатывать некому, так что данный проект поручен холдингу “Сириус”, владельцу части акций компании “Альт Линукс”, разработчика российского линуха- Alt Linux, стартанувшего в начале 2Yk из руссификации Mandrake. Не знаю что он представляет из себя сейчас, но пять лет назад это был выпиленный на коленке дистрибутив, чьим основным достоинством являлся родной русский. Так что, откровенно говоря, вызывает большое сомнение то что за 2 года удастся сделать то, что делалось десятилетиями и большая вероятность, что разработка национальной ОС будет представлять из себя темизацию рабочего стола, по аналогии с лулзом полуторагодичной давности, запущенным уральским школьником Денисом Поповым, который явил миру собственный линух BolgenOS, явившимся по сути обычной Ubuntu с потертыми GNU’шными лицензиями, темизированным рабочим столом и переименованными пакетами: clamav, tar, gimp, arora и другими. Так что школьник сделал это по глупости и бахвальству, подхваченному учителями и растиражированному СМИ, а вот большие и хитрые дядьки в костюмах, поняли, что все эти смехуечки вокруг школьника с проведением аналогий с Петриком- отличная тема для заработка и сразу же не растерявшись, стали проводить изыскания на тему того, как за 2 года разработать собственный Linux. Посмотрим что нам явят в этот раз, но скорее всего это будет либо Ubuntu либо слака или мандрива, так как бодаться с новеллом или редхатом, перепилив собственно суську или центосину, наши навряд ли станут.

Главное чтобы не KremlinBSD..
хотя если национальная ОС будет именоваться SpizdiliBSD то звучать должно более достойно..
или же просто и понятно  FreeBDS.Raspil Edition

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

После этого запускаем сервер Xming на стороне виндовой машины и настраиваем подключение, запустив программу XLaunch:
Multiple Window -> Start a program -> в Run Remote выбираем Using PuTTY и прописываем логин информацию к CentOS серверу через SSH  -> Additional parametrs можем оставить пустыми, либо прописать свойства терминала Х и ssh соединения ->  Готово

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

# xeyes &
или
# blackjack &

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

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

В процессе настройки в какой то момент в логах появилось неприятное сообщение о том, что пакеты дропаются стороной CentOS сервера, что вылечилось добавлением в файл X-сервера Xming виндусовой машины C:\Program Files\Xming\X0.hosts строчки, содержащей IP адрес нашего CentOS сервера. Но это скорее исключение из правил, ибо все работает и без этого.

Начну с того что я остановился сразу на платформе Asterisc, во первых потому что это наиболее популярный open-sourse, во-вторых потому что по данной платформе огромное количество полезной информации в интернете.

Погуглив, почитав и пообщавшись по форумам с людьми, выявил для себя следующие моменты:
под платформу лучше всего использовать отдельный сервер, поскольку на виртуалке могут возникнуть траблы как с трафом, так и с производительными мощностями, особенно в случае если трафик от провайдера приходит в одном кодеке, а в офисе мы используем другой;
для дедика вполне хватит сore2 или core i3, как минимум с 2Гб оперативы на борту, так что на первое время вполне сгодится какой нить десктоп, если руководство жмет деньги на приобретение полноценного сервера;
использовать лучше кодек g711, при этом под каждый активный разговор отводится порядка 64 кбит/с, так что умножаем на это число количество входящих линий и получаем необходимую под VoIP полосу пропускания;
использовать можно FreeBSD или CentOS, хотя тут мнения разделяются, как собственно и в любой холиваре- единственное что я пока осознал, что обновления для платформы Asterisc выходят на Cent OS с большим опозданием, по сравнению с фрей;
для сервака лучше использовать внешний, отдельный IP, поскольку при пробросе SIP портов (5060 udp/tcp и выделенный upd диапазон для траффа) через NAT могут возникнуть проблемы (в моем случае точно, поскольку на D-Link’e эти проблемы возникли даже при пробросе rdp);
можно использовать аналоговые телефоны, но для них придется докупать либо специальную карту в сервер, чья стоимость составляет около 2к грина, либо же VoIP шлюз, который также стоит в районе 200 грин;
цены на IP-телефоны начинают от 4к за более менее нормальные аппараты, так что имеет резон использовать бесплатные софтовые клиенты, так как в этом случае контора попадает только на гарнитуры, чья стоимость составляет от 700 рублей за штуку;
если планируется иметь факс, то его лучше вешать на аналоговую линию, поскольку для передачи факсимильных сообщений требуется идеализированный траффик, в противном случае факсы будут приходить крайне отстойного качества;
сама платформа Asterisc метит траффик, так что использовать для него приоритезацию траффика QoS не составляет проблемы;
некоторые провайдеры имеют свойство зафильтровывать SIP траффик, чтобы потенциальные клиенты не пользовались сторонними сервисами, так что придется либо брать данный вид трафа у этого провайдера, либо же каким то образом договариваться с ним;
в этом же ключе я пробивал возможность использования VoIP со шлюзом Checkpoint, который я уже успел несколько подзабыть за прошедшие полгода, в связи с чем выяснилось несколько моментов: в стандартной поставке Checkpoint FW будет корректно обрабатывать и пропускать VoIP траффик, и даже фильтровать его по политикам безопасности (при заведении объекта шлюза VoIP), а также симафорить с помощью IPS блейда, имеющего стандартными несколько сигнатур для проверки VoIP траффика. Но есть хочется чего то большего, то необходимо приобретать блейд  Voice over IP (VoIP) Software Blade, который этих сигнатур имеет большее количество и к тому же может не только проверять VoIP траффик, но и при необходимости вносить изменения в пакеты: транслировать адреса или вносить исправления в заголовки. Единственный момент здесь в том, что данный блейд встает только на версию R65, то есть весьма и весьма древнюю, так как на новых версиях SPLAT данный блейд не работает.

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

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

Схема работы простая: есть юниксовый сервер UNIX-Server под управлением CentOS на котором крутится X-клиент/сервер; есть виндовая машинка Win-XP на которой поднимается X-сервер Xming с помощью которого мы подключаемся к клиентской части UNIX-Server и по идее должны получить картинку с X-терминалом на рабочем столе виндовой машины.

Для начала скачиваем и устанавливаем на нашу Win-XP рабочую станцию X-сервер  Xming, откуда нить с инетовского зеркала, благо их предостаточно разбросано по инету. После установки пробуем настроить работу через Xdmcp.  Это специфический незашифрованный протокол, используемый для аутентификации и подключения Х-сервера к Х-клиенту.  Поскольку он не является закрытым, то его не рекомендуется использовать в открытых сетях, но это ограничение убирается при использовании сторонних средств шифрования. Ибо это наше первое знакомство, то не будем запариваться на безопасность и попробуем хотя бы запустить данный сервис.

Для этого на UNIX-Server открываем файло  /usr/share/config/kdm/kdmrc и в разделе [Xdmcp] проверяем, чтобы активность равенства Enable=true
После этого добавляем в файлы следующие поля:

/etc/gdm/custom.conf
[xdmcp]
Enable=true

/etc/X11/fs/config
# no-listen = tcp

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

Перегружаем Х-сервер
# /etc/rc.d/init.d/xfs restart
после чего переходим к настройке виндового сервера. Запускаем приложение XLaunch, в котором выбираем
One Window -> Open session via XDMCP -> в Connect to host прописываем IP адрес UNIX-Server и ставим галку Use indirect connect (народ пишет, что её надо снять но в нашем случае заработало только с ней) -> можем оставить пустыми, либо прописать свойства терминала Х, например в Remote font server наш IP UNIX-Server, а в Additional parametrs for Xming строку инициализации десктопа без кавычек “-screen 0 800×600″ ->  Готово

Если все настроили правильно, то на выходе получаем консоль с приглашением нашего X-терминала.

Собственно в CentOS процесс загрузки работает по принципу System V и расписан в файле  /etc/inittab, точнее расписано то как процесс INIT отрабатывает уровни загрузки. В системе фалы загрузки находятся в каталоге /etc/rc.d и носят названия rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, и rc6.d. Пользователи могут размещать файлы в этих каталогах которые будут контролировать запуск сервисов в системе.В свою очередь эти фалы линкуются на каталог /etc/rc.d/init.d и содержащиеся в них скрипты запуска процессов. В этой связи для запуска сервиса необходимо создать полноценный файл запуска сервиса в /etc/init.d, после чего задать символический линк на него из папки соответствующей тому уровню запуска, на котором необходимо стартовать данный сервис. Файлик запуска сервиса будет выглядеть следующим образом, хотя можно расписать все  пару строк просто строкой запуска сервиса:

#!/bin/bash
#
# chkconfig: 35 90 12
# description: Foo server
#

exit 0

Если нет желания заморачиваться с написанием скрипта, то можно добавить строку инициализации запуска сервиса в файл /etc/rc.local. Это файл будет отработан в самом конце загрузки системы, но перед выдачей меню логина.

Для добавления сервисов находящихся в попдапках rc0.d – rc6.d в автозагрузку в системе есть специальная утилита chkconfig, с помощью которой можно добавлять или исключать сервисы.

# chkconfig -l service_name # просмотреть уровни автозагрузки сервиса
# chkconfig  –level 34 service_name on|off|reset # вкключить или выключить сервис на 3 и 4 уровнях
# chkconfig  –del service_ name # удалить службу
# chkconfig  service_name on|off # включить или выключить службу на всех уровнях
ну и есессно главная команда:
# man chkconfig

Помимо этого можно воспользоваться утилитой ntsysv , для редактирования всех уровней или задач редактирования для определенного уровня:
# ntsysv –level 34

Для этого необходимо создать bonding интерфейс, путем создания файла /etc/sysconfig/network-scripts/ifcfg-bond<N> , где N номер объединяемого интерфейса. Содержимое файла аналогично содержимому файла описания настроек обычно интерфейса, с той разницей что директива DEVICE= должна содержать поле bond<N>, где N номер интерфейса.

Пример файла выглядит следующим образом:
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.1.0
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no

После того как файлы будут созданы, можно объединять интерфейсы путем добавления директив MASTER= и SLAVE=  , так что за исключением этих полей оба файла должны выглядеть идентично. Например для интерфейсов eth0 и eth1файлы конфигурации будут выглядеть следующим образом:
DEVICE=eth<N>
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Для того чтобы  слияние интерфейсов работало, необходимо чтобы модуль bonding был загружен в ядро, для чего необходимо проверить, чтобы в файле /etc/modules.conf присутствовала строка:
alias bond<N> bonding
где N номер интерфейса, и для каждого сконфигурированного интерфейса должна присутствовать своя запись.

Смена IP производится следующим образом:
Открываем файлец /etc/sysconfig/network-scripts/ifcfg-eth0 и смотрим что мы в нем имеем:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes

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

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes
DHCP_HOSTNAME=crm_security.lan
IPADDR= новый_IP_адрес
NETMASK=255.255.255.0
GATEWAY= новый_шлюз
TYPE=Ethernet

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

Теперь по поводу алиасов- там же где мы правили файло с сетевыми настройками, создаем файлик ifcfg-<if-name>:<alias-value> Единственно что надо учесть тот момент что алиас не может цеплять свой адрес по DHCP, поэтому следует задавать статический адрес, для чего создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0:0 и в него прописываем следующие строки:

DEVICE=eth0:0
ONBOOT=yes
BOOTPROTO=static
IPADDR=алиас_IP
NETMASK=255.255.255.255

Если нужно добавить пул алиасов, скажем от 192.168.10.1 до 192.168.10.200, то сделать это можно либо создав 200 конфигурационных файлов для алиаса, либо описав весь пул адресов, для чего создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0 и внесем в него следующие строки:

IPADDR_START= 192.168.10.1 # первый IP в пуле
IPADDR_END= 192.168.10.200 # последний IP в пуле
NETMASK=255.255.255.255
CLONENUM_START=1 # число <alias-value> с которого будет начинаться пул
NO_ALIASROUTING=yes

После этого с ManageEngine скачиваем SupportCenter (http://www.manageengine.com/products/support-center/download.html) естественно для Linux. Кладем наше богатство в папку /tmp и устанавливаем путем который я описывал ранее в установке приложений для Linux систем:

# mv ManageEngine_SupportCenter_Plus.bin /tmp/
# cd /tmp/
# chmod 754 ManageEngine_SupportCenter_Plus.bin
# ./ManageEngine_SupportCenter_Plus.bin

Последняя команда вызовет диалог установки приложения.
Путь установки: /root/AdventNet/ME/SupportCenter
Выбираем тип установки FreeEdition, который дает возможность завести один технический аккаунт и сколько угодно много аккаунтов клиентов.  Порт веб-сервера выберем произвольный, например 4896, и в качестве используемого СУБД – MySQL.

Установка закончена, теперь необходимо запустить сервер:

# cd /root/ManageEngine/ServiceDesk/bin/
# sh run.sh

Процесс запуска занимает несколько минут, после чего мы можем через бродилку обратиться к серверу: http://localhost:4896
Логин для входа в администраторский раздел:
Username     :     administrator
Password     :     administrator

Мы сразу же попадаем в раздел администрирования, где запускается мастер настройки системы там мы расставляем галочки по мере необходимости тех или иных опионов нашего сервис деска, а также настраиваем внешнее подключение к сервису: Organization Settings -> Settings, там мы выставляем настройки контактов и адреса сервера.

После недели гугления получился небольшой списочек из 4-5 кандидатов на звание самого – самого, естественно что меня интересовали бесплатные и условно бесплатные движки. Перепробовав весь список и даже больше, ибо на Hostgatore, как оказалось в состав предлагаемых движков доступных через Fantastico de Luxe помимо множества бордов, CMS и магазинов, также входит 7 различных систем Service Desk, правда все они оказались этакими кастрированными версиями для организации службы поддержки, быстро и на коленке. Наиболее меня впечатлила система osTicket, на её базе вполне можно организовать простенький сервис деск исключительно для общения со службой поддержки через сайт. Но я искал более продуманную систему, поэтому поразмысли остановился на системе SupportCenter Plus от компании ManageEngine.

Система доступна в вариантах под Windows и под Linux, и представляет огромный функционал: почтовые ответы с использованием внешних почтовых систем, базу знаний, интеграцию с форумами, центральное управление учетными записями, каталог продукции, синхронизация БД, интеграция с AD и Outlook, генерацию отчетов. На сайте компании ManageEngine доступны два ознакомительных варианта: 30-ти дневный trial (двух версий Standard и Professional), а также так называемый Free Edition, дающий возможность управления 25 аккаунтами и функционал Standard Edition.

Система устанавливается на RedHat Linux 7.x и Debian 3.0, а также Windows 2000 Prof и XP, Server 2000/2003. В установочном комплекте идет движок БД MySQL, а также поддержка MS SQL 2000/2005 и большинства серверов SQL.

По стоимости получается: от 500 бачинcких за двух технарей в Standard Edition и от $1000 за двух инженеров в Professional Edition.

Сервер крутится под Cent OS 5.2, хотя судя по всему все это же действительно и для RHEL . Для начала мы приходим к тому, что не смотря на то, что сервер NFS отсутствует в возможных вариантах установок, он как класс присутствует в системе.
Скрипт запуска сервера находится /etc/init.d/nfs, конфиг сервера /system/config/nfs

Создаем папки для выгрузки логов:

# mkdir -p /archive/phemars                                 # второй каталог аналогичен имени MARS Box
# chown -R nobody:nobody /archive
# chmod -R 777 /archive

В конфигурационный файл /etc/exports задаем каталог, опции монтирования и IP-клиента для каталога выгрузки

/archive/phemars    MARS_IP_Address    (rw)

после изменения этого файла необходимо рестартнуть (reload) демона nfs.

Рестартуем сам сервис

# /etc/init.d/nfs restart

После чего на циске говорим:

# export config IP-Server:/archive/phemars

и получаем ошибку что невозможно подмонтировать. Включив мозг мы приходим к тому, что надо смотреть tcpdump и  логи, откуда выясняем что на нашей системе по умолчанию крутится фаервол iptables, т.ч. открываем на редактирование свод его правил (/etc/sysconfig/iptables), либо задаем правила из командной строки, и открываем следующие порты:

### Для RPC
-A INPUT -i eth0 -p tcp -m tcp –dport 111 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 111 -j ACCEPT
### Для NFS
-A INPUT -i eth0 -p tcp -m tcp –dport 2049 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 2049 -j ACCEPT
### Для rpc.statd
-A INPUT -i eth0 -p tcp -m tcp –dport 4000 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4000 -j ACCEPT
### Для lockd
-A INPUT -i eth0 -p tcp -m tcp –dport 4001 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4001 -j ACCEPT
### Для mountd
-A INPUT -i eth0 -p tcp -m tcp –dport 4002  -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4002  -j ACCEPT
### Для rpc.rquota
-A INPUT -i eth0 -p tcp -m tcp –dport 4003  -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4003 -j ACCEPT

########  или же одним веским словом для 4 последних
-A INPUT -i eth0 -p tcp -m tcp –dport 4000:4003  -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4000:4003 -j ACCEPT

Также следует указать следующие параметры для демонов в файле /etc/sysconfig/nfs
# для сервера rpc.nfsd
RPCNFSDARGS=”–port 2049″

# для сервера mountd
MOUNTD_PORT=4002

# для настройки rpc.rquota новых версий
RQUOTAD_PORT=4003

# для настройки rpc.rquota старых версий необходимо (пакет quota 3.08+) добавить в /etc/services
rquotad 4003/tcp
rquotad 4003/udp

# для сервера lockd
LOCKD_TCPPORT=4001
LOCKD_UDPPORT=4001

# для сервера блокировки на старых системах следует добавить в /etc/modprobe:
options lockd nlm_udpport=4001 nlm_tcpport=4001

# для сервера rpc.statd
STATD_PORT=4000

#Стартуем все сервисы
service nfs start
service nfslock start

Все, повторяем все действия по выгрузке конфига и видим, что mars выгрузил данный под каким то неопознанным пользователем (у нас его uid был 500), собственно для чего мы и клали маску 777

* Если что то не получается, то можем попытаться подмонтировать том к локальной машине, для чего вносим изменения в файлик /etc/exports , где указываем внешний айпишник лоальной машины и говорим (сосбтвенно так и поймали проблему с пользователями, т.к. локальный mount создает файлы с uid nfsnobody)
mount -t nfs -users eth0_IP:/archive/phemars /mnt

***  В наиболее гиморных местах помогло
очень грамотное описание сервиса
на сайте BOG

Корректный способ, имеющий так же результатом полную очистку очереди сообщений:
service exim stop;
rm -rf /var/spool/exim/input.bak;
mv /var/spool/exim/input /var/spool/exim/input.bak;
mkdir /var/spool/exim/input;
chown mailnull.mail /var/spool/exim/input;
chmod 750 /var/spool/exim/input;
service exim start;

Официальный способ очистки очереди:
exim -qff

Тоже самое с включенным дебаггом процесса:
exim -qff -d9

Собственно все тоже самое можно проделать скриптом. Как условие- все исполняемые файлы должны быть прописаны полностью, и пользователь стартующий скрипт должен быть доверенным для Exim’а.
Также данный скрипт может помочь в ситуации когда после доставки сообщения Exim куда то девает телосообщения, в результате чего письмо становится гостом и в листинге очереди exim -bp объем не указывается, в результате чего exiqgrep, не понимая о чем речь, выпадает с ошибкой.
Собственно скрипт убивающий сообщения из очереди, но оговорюсь сразу- письма уходят навсегда.

#!/bin/bash

# Определяем qualify_domain — он необходим для удаления всяческого мусора
domain=`exim -bP | grep -i “^qualify_domain” | sed -e s/.*\=\ //g`

# Прощаемся со всеми замороженными сообщениями
exim -bpr | grep ‘<' | awk '{print $2}' | grep '-' | xargs exim -Mrm 2> /dev/null

# при передаче скрипту параметра c, включаем агрессивный режим
if [ "$1" == "c" ]; then

# Удаляем все баунсы старше 20 минут
exiqgrep -o 1200 -if ‘^<>$’ |xargs exim -Mrm
# Сносим все сообщения с адресами начинающихся со спец.символов, таких как нижний подчерк, минус или тире
exiqgrep -f ‘^<\_|^<\-|^<\|' -i | xargs exim -Mrm
exiqgrep -r '^\_|^\-|^\|' -i | xargs exim -Mrm
#Выкашиваем сообщения отправленные на китайские домены, за последние 20 минут
exiqgrep -f "$domain" -r '.cn$' -o 1200 -i | xargs exim -Mrm
# Удаляем любые сообщения отправленные скриптами, если они зависли в очереди более чем на 12 часов
exiqgrep -f "$domain" -o 43200 -i | xargs exim -Mrm
exit
fi

# В мягком режиме удаляем только frozen баунсы и письма с невозможными адресами в заголовках
exiqgrep -zif '^<>$’ |xargs exim -Mrm
exiqgrep -f ‘^<\_|^<\-|^<\|’ -i | xargs exim -Mrm
exiqgrep -r ‘^\_|^\-|^\|’ -i | xargs exim -Mrm

##########################################
Работа с очередью Exim.
Когда возникает необходимость удалить одно или несколько замороженных сообщений из очереди, мы прибегаем к утилите Exipick:
exipick – показывает сообщения в очереди экзима
exipick -z – показывает замороженные сообщения
exipick -i – показывает ID сообщений

exim -Mrm ID – удаляет из очереди сообщение с определенным ID

В итоге получаем:
exipick -zi | xargs exim -Mrm //очистит все замороженные сообщения из очереди
exipick -i | xargs exim -Mrm //очистит все сообщения из очереди
exipick -i | xargs exim -Mg // Очистка почтовой очереди в MTA Exim. Сервер пытается немедленно доставить все письма, находящиеся в очереди. Если какое-либо письмо не удалось доставить, оно удаляется из очереди.

autoreply:
driver = accept
require_files = /usr/home/exim/$local_part/.vacation.txt
condition = ${if or { \
{match {$h_precedence:} {(?i) junk|bulk|list}} \
{eq {$sender_address} {}} \
{match {$h_subject:} {(ADV|Adv)}} \
} {no} {yes}}
no_expn
senders = !+noautoreply_senders
transport = address_reply
unseen
no_verify

##########################################################
Раздел TRANSPORTS CONFIGURATION:

address_reply:
driver = autoreply
file = /usr/home/exim/$local_part/.vacation.txt
file_expand
once = /var/log/exim-$local_part-vacation.db
once_repeat = 1d
from = $local_part@odminblog.ru
headers_add = “Auto_Repl:$reply_address”
to = $sender_address
subject = Re: ${rfc2047:$h_subject:}

##########################################################
В разделе MAIN CONFIGURATION определяем местоположение списка исключений для автоответа

addresslist noautoreply_senders = /etc/mail/autorep.noanswer

##########################################################

И собственно определяем сам список доменов, на письма с которых не нужно отсылать автоответ:

##########################################################
#### /etc/mail/autorep.noanswer
##########################################################

^.*-request@.*
^owner-.*@.*
^.*-owner@.*
^.*-admin@.*
^bounce-.*@.*
^.*@bounce\..*
^.*-outgoing@.*
^.*-relay@.*
^.*-bounces@.*
^.*-bounce@.*
^.*-confirm@.*
^.*-errors@.*
^mailer@.*
^postmaster@.*
^mailer-daemon@.*
^mailer_daemon@.*
^majordomo@.*
^majordom@.*
^mailman@.*
^nobody@.*
^reminder@.*
^autoreply.*@.*
^.*-autoresponder@.*
^autoresponder@.*
^listserv@.*
^daemon@.*
^server@.*
^root@.*
^noreply.*@.*
^no-reply@.*
^bounce@.*
^news@.*
^request.*@.*
^httpd@.*
^lighttpd@.*
^www@.*
^www-data@.*
^nagios@.*
^sales@.*
^info@.*
^fetchmail.*@.*
^listmaster@.*
^mailmaster@.*
^webmaster@.*
^squid@.*
^support@.*
^exim@.*
scomp@aol.net

Теперь все что от нас требуется, это своевременно закинуть в домашнюю директорию пользователя файлик .vacation.txt с текстом автоответа. Кодировка по умолчанию будет utf-8

##########################################################
На EximWiki несколько иная конфигурация которая выглядит довольно убедительно, но я её не пробовал, т.ч. просто привожу.
##Router##
uservacation:
driver = accept
domains = +local_domains
condition = ${if or { \
{ match {$h_precedence:} {(?i)junk|bulk|list} } \
{ eq {$sender_address} {} } \
{ def:header_X-Cron-Env: } \
{ def:header_Auto-Submitted: } \
{ def:header_List-Id: } \
{ def:header_List-Help: } \
{ def:header_List-Unsubscribe:} \
{ def:header_List-Subscribe: } \
{ def:header_List-Owner: } \
{ def:header_List-Post: } \
{ def:header_List-Archive: } \
{ def:header_Autorespond: } \
{ def:header_X-Autoresponse: } \
{ def:header_X-Autoreply-From: } \
{ def:header_X-eBay-MailTracker: } \
{ def:header_X-MaxCode-Template: } \
{ match {$h_X-Auto-Response-Suppress: } {OOF} } \
{ match {$h_X-OS:} {HP Onboard Administrator} } \
{ match {$h_X-MimeOLE:} {\N^Produced By phpBB2$\N} } \
{ match {$h_Subject:} {\N^Yahoo! Auto Response$\N} } \
{ match {$h_Subject:} {\N^ezmlm warning$\N} } \
{ match {$h_X-FC-MachineGenerated:} {true} } \
{ match {$message_body} {\N^Your \”cron\” job on\N} } \
{ match {$h_Subject:} {\N^Out of Office\N} } \
{ match {$h_Subject:} {\N^Auto-Reply:\N} } \
{ match {$h_Subject:} {\N^Autoresponse:\N} } \
{ match {$h_Subject:} {\N(Auto Reply)$\N} } \
{ match {$h_Subject:} {\N(Out of Office)$\N} } \
{ match {$h_Subject:} {\Nis out of the office.$\N} } \
{ match {$h_X-Spam-Flag:} {\N^yes\N} } \
{ match {$h_From:} {\N(via the vacation program)\N } } \
} \
} {no} {yes} \
}
require_files = /.vacation.msg
user = ${lc:$local_part}
senders = !+noautoreply_senders
transport = vacation_transport
unseen
no_expn
no_verify
##########################################
##Transport##
vacation_transport:
driver = autoreply
log = /.vacation.log
once = /.vacation.once
once_repeat = 7d
# Errors-To: is deprecated
# There are arguments over whether this should send to the SMTP sender, or
# to a From:, Reply-To: or Resent-From: header
to = “${if def:h_Errors-To: {$h_Errors-To:} {$sender_address}}”
file = /.vacation.msg
return_message
subject = ${if def:h_subject: \
{Auto: Re: ${rfc2047:${quote:${escape:${length_60:$h_subject:}} }} }\
{Auto: I am away from my mail} \
}
user = ${lc:$local_part}

Файлы исключения для автоответа прописываются таким же образом.
##########################################################

Второй способ значительно проще, и подразумевает запущенную связку Exim + DBmail + MySQL. В этом случае мы всего лишь определяем в разделе Transport следующую строку:
address_reply:
driver = autoreply

и в конфигурационном DBMAIL dbmail.conf определяем дерективу отвечающую за использование таблицы auto_reply для автоответа.

AUTO_REPLY = yes

• Пакетные файлы rpm
• Самораспаковывающиеся двоичные файлы bin
• Файлы архивов tar

Пакетные файлы в среде Linux устанавливаются с помощью пакетного менеджера, т.е. процесс установки мало чем отличается от установки виндового exe’шника, два клика, автостарт и набор yes – next. Работа с пакетным менеджером крайне удобна, т.к. позволяет производить управление пакетами, обновление устаревших версий и многое другое. Но иногда менеджер либо не кушает rpm, либо в принципе отсутствует на машине, и тогда приходится возвращаться назад к предтечам, ака терминальной сессии:

Наиболее прямой способ установки пакета, без изысков:

# rpm -ivh sample.i386.rpm

Если пакет уже установлен, или при возникновении каких то ошипок следует задать игнор оных:

# rpm -ivh –replacepkgs sample.i386.rpm

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

# rpm -ivh –replacefiles  sample.i386.rpm

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

Удаление пакета производится с помощью той же команды:

# rpm -e sample

Установщик может начать ругаться о том, что удаляемый пакет связан с существующими в системе, для этого в установке нужно задать игнор зависимостей, уже знакомым нам ключом –nodeps

Обновление пакета производится аналогичным способ:

# rpm -Uvh sample.i386.rpm

В связи с тем что обновление пакетов всегда подразумевает удаление пакета и его установку, то вы можете получить ошибку о том, что пытаетесь заменить пакет на более старую версию, для этого нужно использовать ключ –oldpackage

# rpm -Uvh –oldpackage sample.i386.rpm

или если вы хотите обновиться до новой версии:

# rpm -Fvh sample.i386.rpm

И естетсвенно как обычно рулит  # man rpm

Самораспаковывающиеся двоичные файлы bin устанавливаются простым образом. Переходите в терминале в папку с этим файлом, задаете ему права на запуск:

# chmod a+x sample.bin

и после этого запускаете сам файл

#./sample.bin

Файлы архивов tar устанавливаются большим числом манипуляций, но позволяют более тонко настроить систему в процессе установки. Архивы обычно идут в формате tar.gz Для распаковки архива необходимо задать команду распаковки

# tar -xzvf sample.tar.gz ( или добавить ключ “-c /path-to-unpack” чтобы задать путь для распаковки)

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

# ./configure

# make

# make check

# make install (так же возможные варианты синтаксиса  sudo make install или su -c ‘make install’)

Для вывода доступных функций конфигурации пакета следует задать команду:

# ./configure –help

Также имеется возможность конвертации пакетов rpm в архивы tar, и наоборот, но об этом несколько позже