# yum groupinstall "Development Tools"
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm
# yum install git-core

Устанавливаем пакеты необходимые для сборки wkhtmltopdf:

$ yum install openssl-devel libXrender-devel libXext-devel libXft-devel

Вытягиваем свежие исходники wkhtmltopdf:
$ git clone git://github.com/antialize/wkhtmltopdf.git wkhtmltopdf
$ git clone git://gitorious.org/+wkhtml2pdf/qt/wkhtmltopdf-qt.git wkhtmltopdf-qt

Собираем специальную версию Qt:
$ cd wkhtmltopdf-qt
$ ./configure -nomake tools,examples,demos,docs,translations -opensource -prefix "../wkqt"
$ make -j3 && make install

Собираем wkhtmltopdf:
$ cd ../wkhtmltopdf
$ ../wkqt/bin/qmake
$ make
# make install

Все, после этих простых шагов пакет собран и установлен. Оригинал тут : http://code.google.com/p/wkhtmltopdf/wiki/compilation .

Порядок действий:
1. Подключаем USB камеру к компьютеру и проверяем распознала ли ее систима:
boffin@fortress:~$ ls -la /dev/video*
crw-rw----+ 1 root video 81, 0 2011-07-17 17:35 /dev/video0
2. Ставим VLC:
apt-get install vlc
3. Запускаем потоковое вещание:
vlc -I dummy v4l2:///dev/video0 --sout '#transcode{vcodec=mp4v,vb=800}:standard{access=http,mux=ogg,dst=192.168.1.123:8080}'
Разберем параметры:
-I dummy — VLC запустится без графического интерфейса
vcodec=mp4v,vb=800 — кодек для видео и битрейт
dst=192.168.1.123:8080 — по какому адресу и порту будет доступен видео поток
4. Запускаем VLC на клиентской машине, Media -> Open Network Stream, вводим в поле адрес http://192.168.1.123:8080/
Все, готово.

К сожалению подобный способ трансляции имеет отставание видео которое может доходить до 5 секунд. Трансляция видео 640×480 грузила мой процессор на 100%. С целью разгрузить процессор и уменьшить отставание я понизил разрешение, битрейт и количество кадров в секунду. Получилась такая команда:
vlc -I dummy v4l2:///dev/video0 --sout '#transcode{vcodec=mp4v,vb=400,width=320,height=240,fps=15}:standard{access=http,mux=ogg,dst=192.168.1.123:8080}'
В итоге нагрузка на процессор во время трансляции не подымается выше 45% а видео с отставанием 1-2 секунды передается успещно по Wi-Fi сети.

Функционал ufw
Основными функциями файрвола ufw является:
1. Работа в одном из двух режимов: разрешено все кроме того что описано правилами, запрещено все, кроме описанного правилами.
2. Создание правил для фильтрации пакетов с действиями allow, deny, reject
3. Создание правил с учетом адреса и порта получателя и отправителя, используемого протокола
4. Логирование пакетов подпадающих под правило
5. Блокировка частых неправильных попыток авторизации по ssh
6. Настраиваемые профили для приложений

Запуск ufw
Ufw может быть включен или выключен системным администратором сервера, для этого используется команад:
# ufw enable
Межсетевой экран активен и будет запущен при запуске системы
# ufw disable
Файрвол остановлен и деактивирован при загрузке

Просматривать состояние можно с помощью команды:
# ufw status [numbered]
Статус: активно

Параметр numbered может быть использован для отображения правил файрвола с соответствующей нумерацией.

Изменение политики по умолчания:
# ufw default allow [in|out]
# ufw default deny [in|out]
# ufw default reject [in|out]

Где allow подразумевает что все пакеты будут пропущены, кроме тех, для которых есть запрещающее правило: deny – все пакеты будут заблокированы, кроме тех, для которых есть разрешающие правила; reject – все пакеты будут заблокированы с соответствующим уведомлением подключающуюся сторону.
Параметры in|out указывают для какого направления мы хотим применять политику, для входящих или исходящих пакетов соответственно.

Управление правилами осуществляется с помощью команд allow, deny, reject, delete, insert.
allow – добавить разрешающее правило
deny – добавить запрещающее правило (файрвол не предпринимает действий при попадании в это правило)
reject – добавить запрещающее правило (файрвол даст знать подключающемуся что этот порт закрыт)
limit – добавляет ограничивающее правило для указанного порта. В случае если с одного и того же адреса в течении 30 секунд будет произведено 6 и более неуспешных попыток авторизации в службу удаленного доступа ssh, ufw заблокирует удаленный адрес.
delete – удалить добавленное ранее правило
insert – вставить правило в определенную позицию в цепочке

Построение правил файрвола
Конструкция построения правил
ufw allow|deny|reject|limit [in|out on INTERFACE] [log|log-all] [proto protocol] [from ADDRESS [port PORT]] [to ADDRESS [port PORT]]
Подробнее о параметрах:
allow|deny|reject|limit – указываем что будет делать это правило (см. описание выше).
[in|out on INTERFACE] – указываем будет это правило относится к входящему трафику (in) или исходящему (out) и хотим ли мы ограничить данное правило отдельным сетевым интерфейсом (к примеру eth0).
[log|log-all] – при желании можно логировать события которые подпадают под правило. По умолчанию лог пишется в /var/log/syslog. При использовании опции log – в файл будут записаны лишь пакеты участвующие при установке соединения с сервером. Используя опцию log-all в лог файл будут записаны все пакеты подпадающие под правило.
[proto protocol] – в правиле можно указать для какого протокола оно действует: tcp или udp.
[from ADDRESS [port PORT]] – адрес и порт источника пакета
[to ADDRESS [port PORT]] – адрес и порт получателя пакета

Профили приложений
Ufw позволяет создавать профили приложений. в которых можно указать все порты которые используются и удобно добавлять их в правила. Так к примеру можно создать профиль для веб-сервера Apache, указав что слушает он 80 и 443 порты по протоколу tcp.
Профили приложений являются текстовыми файлами и могут быть отредактированы любым текстовым редактором. все файлы хранятся в директории /etc/ufw/applications.d:
root@server:/etc/ufw/applications.d# pwd
/etc/ufw/applications.d
root@server:/etc/ufw/applications.d# ls -l
итого 12
-rw-r--r-- 1 root root 406 2009-11-13 00:52 apache2.2-common
-rw-r--r-- 1 root root 145 2009-10-22 22:50 openssh-server
-rw-r--r-- 1 root root 241 2009-09-22 16:52 postfix

Рассмотрим пример профиля приложения apache2.2-common:
[Apache]
title=Web Server
description=Apache v2 is the next generation of the omnipresent Apache web server.
ports=80/tcp
[Apache Secure]
title=Web Server (HTTPS)
description=Apache v2 is the next generation of the omnipresent Apache web server.
ports=443/tcp
[Apache Full]
title=Web Server (HTTP,HTTPS)
description=Apache v2 is the next generation of the omnipresent Apache web server.
ports=80,443/tcp
В одном файле может находится несколько профилей. В данном примере 3: Apache, Apache Secure, Apache Full. Структура записей проста: сначала имя профиля в квадратных скобка ([Apache Full]), далее развернутое наименования приложения, далее описание приложения и список портов с указанием протокола которые задействованы в профиле (80,443/tcp).

Вывести список профилей можно с помощью команды:
# ufw app list
Доступные приложения:
Apache
Apache Full
Apache Secure
OpenSSH
Postfix
Postfix Submission

Детальную информацию по профилю можно просмотреть с помощью команды:
# ufw app info OpenSSH
Профиль: OpenSSH
Название: Secure shell server, an rshd replacement
Описание: OpenSSH is a free implementation of the Secure Shell
protocol.
Порт:
22/tcp
После добавления или изменения профиля приложения (в файле) необходимо дать знать файрволу о новом профиле:
# ufw app update OpenSSH

Для того что б новый профиль сразу вступил в силу, необходимо добавить опцию —add-new:

# ufw app update --add-new OpenSSH

По умолчанию добавленные с помощью —add-new профили не будут обрабатываться файрволом. Рекомендуется вначале задать политику для новых профилей приложений:
ufw app default allow|deny
После чего все новые профили приложений будут добавляться в цепочку файрвола с указанной политикой.

Использовать профили приложений можно также при создании обычных правил, например:
# ufw allow OpenSSH

Настройка профиля безопасности
1. Ограничение входящих подключений к FTP и Веб серверу
Пример настройки файрвола для ситуации, когда необходимо заблокировать доступ к FTP и Веб серверу с адреса 192.168.100.100. В примере 192.168.1.11 — сервер на котором настраивается файрвол:

root@server:/etc/ufw/applications.d# ufw deny proto tcp from 192.168.100.100 to 192.168.1.11 port 21,80
Правило добавлено
root@server:/etc/ufw/applications.d# ufw status
Статус: активно
До Действие От
---- --------------------
192.168.1.11 21,80/tcp DENY 192.168.100.100

Теперь при попытках подключения с хоста 192.168.100.100 к 21 или 80 порту хоста 192.168.1.11 клиент будет висеть пока не отвалится по таймауту.

Удалим это правило и добавить аналогичное но с действием reject:
# ufw delete deny proto tcp from 192.168.100.100 to 192.168.1.11 port 21,80
# ufw reject proto tcp from 192.168.100.100 to 192.168.1.11 port 21,80

Теперь при попытке подключения к 21 порту сервера удаленный клиент получит ответ Connection refused:
$ telnet 192.168.1.11 21
Trying 192.168.1.11...
telnet: Unable to connect to remote host: Connection refused

Просканируем порты сервера:
:~# nmap -sT 192.168.1.100
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-28 22:56 EET
Interesting ports on 192.168.1.100:
Not shown: 992 closed ports
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp open ssh
80/tcp filtered http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
2323/tcp open unknown
3128/tcp open squid-http
5900/tcp open vnc
MAC Address: 00:18:F3:67:85:9E (Asustek Computer)
Nmap done: 1 IP address (1 host up) scanned in 17.52 seconds

2. Ограничение исходящих подключений к указанному серверу
Цель — запретить исходящие подключения с сервера к адресу 195.214.195.105:

# ufw deny proto tcp to 195.214.195.105

3. Ограничение попыток авторизации по ssh
# ufw limit 22

Произведем несколько попыток подключения к 22 порту сервера с введением заведомо неправильного пароля:
user@remote:~$ ssh 192.168.1.100
user@192.168.1.100's password:
Permission denied, please try again.
user@192.168.1.100's password:
user@remote:~$ ssh 192.168.1.100
user@192.168.1.100's password:
Permission denied, please try again.
user@192.168.1.100's password:
user@remote:~$ ssh 192.168.1.100
user@192.168.1.100's password:
Permission denied, please try again.
user@192.168.1.100's password:
user@remote:~$
user@remote:~$ ssh 192.168.1.100
ssh: connect to host 192.168.1.100 port 22: Connection refused
user@remote:~$ ssh 192.168.1.100
ssh: connect to host 192.168.1.100 port 22: Connection refused

Как видим после нескольких неудачных попыток файрвол блокирует IP адрес с которого исходят попытки подключения и в логах появится соответсвтующяя запись:
Dec 28 22:59:13 fortress kernel: [273659.578463] [UFW LIMIT BLOCK] IN=eth0 OUT= MAC=00:18:f3:67:85:9e:00:26:5e:46:40:86:08:00 SRC=192.168.1.156 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3150 DF PROTO=TCP SPT=33783 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 28 22:59:15 fortress kernel: [273661.231264] [UFW LIMIT BLOCK] IN=eth0 OUT= MAC=00:18:f3:67:85:9e:00:26:5e:46:40:86:08:00 SRC=192.168.1.156 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=763 DF PROTO=TCP SPT=33784 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

4. Логирование пакетов
# ufw allow log 22

С помощью этого правила файрвол будет логировать пакеты установки соединиения по указанному 22 порту. В логах появятся следующие записи:
Dec 28 23:04:18 fortress kernel: [273964.364715] [UFW ALLOW] IN=eth0 OUT= MAC=00:18:f3:67:85:9e:00:26:5e:46:40:86:08:00 SRC=192.168.1.156 DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6564 DF PROTO=TCP SPT=58069 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Итак, представим ситуацию, вы управляете 10 серверами, и на каждом к примеру вам надо установить одинаковый софт. Что первое приходит в голову? Заходить на каждый из серверов и вставлять из буфера обмена команды для установки нужного вам ПО? Но ведь это не Linux Style!

Добрые люди давно придумали средство для распределенного администрирования серверов — dsh (Distributed shell). Другими словами — это программа которая получает на вход команду и распространяет ее по необходимому количеству серверов, выполняет там и выдает вам результат.

Для начала надо определится с какого сервера мы будет давать команды. Этот сервер я буду называть главным. Именно на нем и надо поставить пакет dsh:

sudo apt-get install dsh

Дальше необходимо на каждом из серверов, которым мы будем управлять поставить сертификаты для входа по ssh без пароля (желаетельно сертификаты делять для полтьзователя root, тогда не возникнет проблем, к примеру, при установке ПО или перезапуске Apache):

$ sudo -i
# ssh-keygen -t rsa
# scp id_rsa.pub server1:~/.ssh/authorized_keys
# scp id_rsa.pub server2:~/.ssh/authorized_keys
...
# scp id_rsa.pub server10:~/.ssh/authorized_keys

Теперь с главного должно быть возможным логинится на подчиненные по ssh без пароля. Если не получилось, обратитесь к статье Настройка ssh атворизации по ключу.

Далее необходимо настроить группы серверов.
В файле /etc/dsh/group/all перечисляем все наши сервера:
server1
server2
server3
server4
server5
server6
server7
server8
server9
server10

К примеру сервера 1,2 — сервера баз данных, 3,4 — файловые сервера, а 5-10 — веб ноды. Тогда есть смысл сгрпировать их по предназначению. Для этого создаем файлики:
/etc/dsh/group/db:
server1
server2

/etc/dsh/group/ftp
server3
server4

/etc/dsh/group/web
server5
server6
server7
server8
server9
server10

Когда dsh настроен, приступаем к использованию.
Пробуем выполнить:
dsh -g all uptime
если установка сертификатов прошла успешно, dsh выполнит uptime на всех серверах и выведет вам результат. Если вы увидите запрос на ввод пароля, значит сертификаты не поставились правильно и их желательно поправить.

По умолчанию, dsh выводит просто результат выполнения команды. Очень часто важно видеть с какого-же сервера пришел ответ. Для этого нужен ключ -M, который в начале строки будет отображать имя машины, на которой выполнена команда (имя берется из конфигурационного файла dsh, а не из hostname машины).

# dsh -g web -M "/etc/init.d/apache2 status"
server5: * Apache is running (pid 26433).
server6: * Apache is running (pid 24787).
server7: * Apache is running (pid 21304).
server8: * Apache is running (pid 19856).
server9: * Apache is running (pid 17266).
server10: * Apache is running (pid 26343).

Ну вот и все, это и есть основы dsh. Немножко больше можно научится делать, почитав man.

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

Важно постараться поставить как можно меньше программного обеспечения на физический сервер, в идеале это только OpenVZ и OpenSSH.

Ну а теперь непосредственно процедура установки и настройки OpenVZ (в моих примерах предполагается что у вас установлена свежая Ubuntu 9.04 Server, без дополнительного ПО):

1. Подготовка места на диске для хранения виртуальных машин
Для удобства работы и масштабируемости сервера рекомендуется иметь отдельный жесткий диск ( а лучше два, в рейде, для зеркалирования данных пользователя). Предлагаю в корне создать директорию /vz. В эту директорию монтировать жесткий диск. Для этого в /etc/fstab необходимо добавить строчку:
/dev/sdb1 /vz ext3 defaults 0 0
где /dev/sdb1 — ваш жесткий диск для хранения виртуальных машин.

2. Установка ядра системы с поддержкой виртуализации
Для этого стоит выполнить команду:
# apt-get install vzctl
пакетный менеджер автоматически подтянет ядро с поддержкой openvz нужной версии. В моем случае был установлен linux-image-2.6.26-2-openvz.
После перезагрузки необходимо произвести настройку ядра, редактируем файл /etc/sysctl.conf и меняем следующие строки:

net.ipv4.ip_forward=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
kernel.sysrq = 1

После сохранения файла необходимо применить новые параметры ядра:
# sysctl -p

3. Установка виртуальной машины (гостевой системы)
Для начала необходимо скачать образ операционной системы, которая будет использоваться в гостевой системе. Для этого выбираем на образ на сайте http://openvz.org/download/template/cache/ и скачиваем его в директорию /vz/template/cache:

# mkdir -p /vz/template/cache
# cd /vz/template/cache
# wget http://download.openvz.org/template/precreated/ubuntu-9.04-x86_64.tar.gz

В моем случае для гостевой операционной системы была выбрана Ubuntu 9.04.

Далее необходимо создать непосредственно виртуальную машину, на основе нашего образа. Так как на VPS хостинге эту задачу надо будет повторять неоднократно, удобно использовать скрипт:

root_pw="root_password" # пароль пользователя root в гостевой системе
os_template="ubuntu-9.04-x86_64" # имя образа ОС для гостевой системы
vm_id="1" # идентификатор гостевой системы
/usr/sbin/vzctl create ${vm_id} --ostemplate ${os_template} --config vps.basic #создание гостевой системы на основе образа
/usr/sbin/vzctl set ${vm_id} --onboot yes --save # запускать гостевую при старте системы
/usr/sbin/vzctl set ${vm_id} --hostname vps${vm_id}.domain.com --save #установить hostname гостевой
/usr/sbin/vzctl set ${vm_id} --ipadd 192.168.1.190 --save #установить IP адрес
/usr/sbin/vzctl set ${vm_id} --nameserver 192.168.1.12 --save #установить адрес ДНС сервера
/usr/sbin/vzctl set ${vm_id} --userpasswd root:${root_pw} --save #установить пароль пользователя root
/usr/sbin/vzctl set ${vm_id} --cpulimit 15 --save #установка процессорной квоты 15%
#установка дисковой квоты 9 GB (10 GB в течении промежутка 600 секунд)
/usr/sbin/vzctl set ${vm_id} --diskspace 9000000:10000000 --save
/usr/sbin/vzctl set ${vm_id} --quotatime 600 --save
#установка квоты на виртуальную память 160M (168M в течение quotatime - см.выше)
#с гарантией выделения до 120M (128M)
/usr/sbin/vzctl set ${vm_id} --privvmpages 160M:168M --save
/usr/sbin/vzctl set ${vm_id} --vmguarpages 120M:128M --save
/usr/sbin/vzctl start ${vm_id} #запуск новой гостевой системы


Все, теперь в гостевую систему можно логинится по ssh.

Далее необходимо скопировать открытый ключ на удаленную машину в файл ~/.ssh/authorized_keys. Если такой файл уже существует рекомендуется дописать новый ключ в конец этого файла, таким образом будет возможно логинится на сервер с разных компьютеров по ключу.
boffin@fortress:~/.ssh$ scp id_rsa.pub einstein:~/.ssh/authorized_keys
boffin@einstein's password:
id_rsa.pub 100% 397 0.4KB/s 00:00


В общем, если настройки sshd на удаленной машине установлены по умолчанию, то уже можно логинится:
boffin@fortress:~/.ssh$ ssh einstein
System information as of Mon Sep 14 09:00:01 EEST 2009
System load: 0.18 Memory usage: 35% Processes: 87
Usage of /: 6.3% of 71.98GB Swap usage: 5% Users logged in: 1
Last login: Mon Sep 14 09:03:44 2009 from remotehost.com
boffin@einstein:~$


Если с первого раза удаленная машина не пускает по ключу, следует проверить настройки sshd, убедитесь что в /etc/ssh/sshd_config параметры выставлены следующим образом:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys


Никогда не помешает иметь под рукой настроенный SMTP сервер. В этих целях я решил поставить exim4. Письма будут отправлятся через вне шний SMTP сервер.

А сделать надо не так уж и много:

1. Установить exim

# apt-get install exim4

2. Настройка

В файле /etc/exim4/update-exim4.conf.conf изменить:

dc_eximconfig_configtype=’smarthost’
dc_smarthost=’smtp.gmail.com::587′

3. Настройка авторизации для аккаунта внешнего SMTP, для этого в файл /etc/exim4/passwd.client добавляем

*.google.com:username@gmail.com:password
smtp.gmail.com:username@gmail.com:password
gmail-smtp.l.google.com:username@gmail.com:password

Где вместо username и password вписываем свои данные.

4. Просим exim перечитать конфигурацию:

# update-exim4.conf

Проверить работоспособность можно выполнив

#echo test message | sendmail test@mail.com

2. Скрипт

#!/bin/bash
#выводим текущюю дату и время
date
#указываем бэкапный раздел
DEVICE=/dev/sdc1
#указываем точку монтирования бэкапного раздела
MOUNTPOINT=/mnt/backup
#указываем название временной директории
date=`date +"%Y%m%d"`
DIR=$MOUNTPOINT/dbs_$date
#монтируем бэкапный раздел
echo "Mounting backup device"
mount $DEVICE $MOUNTPOINT
echo "Dumping MySQL databases"
mkdir $DIR
#получаем список баз данных
for i in `mysql -uroot -ppassword -e "show databases" | grep -v information_schema | grep -v Database`
do
#дампим каждую базу в файл во временной директории
mysqldump -uroot -ppassword $i > $DIR/$i.sql
done
#архивируем директорию с дампами
echo "Gzipping databases dumps"
tar czvf $DIR.tar.gz $DIR
#удаляем временную директорию
echo "Removing tmp db dumps"
rm -r $DIR
#отмонтируем бэкапный раздел
echo "Backup finished!"
umount $MOUNTPOINT
date


3. Восстановление
В результате работы скрипта на бэкапном разделе мы будем иметь файлы с видом dbs_20081203.tar.gz. Чтобы восстановить базы надо разархивировать их дампы:
tar zxvf dbs_20081203.tar.gz
и заинсертить эти дампы в базу
mysql -uroot -ppassword db_name < dbs_20081203/db_name.sql

4. Автоматизация
Ну и какой же это бэкап если его надо делать руками =). Добавляем этот скрипт на автоматическое выполнение каждый понедельник в 01:01 в /etc/crontab:
1 1 * * 1 root /bin/bash /root/backuper.sh

На днях возникла необходимость предоставить удобный доступ к файлам сервера Windows машинам. Установка и настройка Samba севрера достаточно проста и быстра.

1. Установка Samba
apt-get install samba

2. Настройка демона Samba
Главный конфигурационный файл демона /etc/samba/smb.conf. Его я отредактировал следующим образом:

[global]
workgroup = HOMEWORKGROUP
server string = Boffin home server
; Для того что б слушать самбой не на всех интерфейсах
bind interfaces only = yes
interfaces = eth0 192.168.1.100
; Список хостов которым разрешен доступ
hosts deny = ALL
hosts allow = 192.168.1.100 192.168.1.150 127.0.0.1
announce version = 5.0
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
passdb backend = tdbsam
security = user
null passwords = true
; Файл с адиасами имен юзеров
username map = /etc/samba/smbusers
name resolve order = hosts wins bcast
wins support = yes
printing = CUPS
printcap name = CUPS
log file = /var/log/samba/log.%m
syslog = 0
syslog only = no
unix charset = utf8
dos charset = cp1251
display charset = cp1251
;название под которым будет доступна директория
[Storage]
; Путь к расшареной директории
path = /mnt/storage
; Разрешен ли просмотр
browseable = yes
read only = no
guest ok = no
create mask = 0644
directory mask = 0755


3. Добавляем пользователей которым разрешён доступ и устанавливаем пароль
smbpasswd -a boffin

4. Активируем пользователя
smbpasswd -e boffin

5. В /etc/samba/smbusers помещаем алиасы (имена пользователей виндовых систем, которым будет предоставлен доступ от имени boffin):
boffin = Admin Administrator

6. Перезапускаем Samba
/etc/init.d/samba restart

7. Проверка работоспособности
boffin@boffin-desktop:~$ smbclient //192.168.1.100/Storage
Enter boffin's password:
Domain=[FORTRESS-SERVER] OS=[Unix] Server=[Samba 3.2.5]
smb: \> ls
. D 0 Wed Dec 3 11:02:08 2008
.. D 0 Thu Sep 11 11:22:07 2008
downloads D 0 Tue Dec 2 13:45:26 2008
restore D 0 Thu Oct 30 12:29:36 2008
trash D 0 Wed Dec 3 11:02:25 2008
lost+found D 0 Wed Oct 29 20:20:07 2008
photo D 0 Sun Nov 30 20:38:23 2008
multimedia D 0 Wed Dec 3 10:50:06 2008
install D 0 Thu Nov 13 09:34:14 2008
docs D 0 Wed Dec 3 10:59:18 2008
UkraineAuto.rar 131 Thu Nov 6 15:52:03 2008
.Trash-1000 DH 0 Wed Nov 12 21:39:53 2008
59146 blocks of size 16777216. 48672 blocks available
smb: \>