Различные настройки Samba для разных клиентов

Samba умеет определять, какие настройки применять для различных подключенных к ней клиентов. Иногда это очень выручает. Для этого используются, во-первых, внутренние переменные (%m, %I и так далее), во-вторых, опции config file и include. 

Если вкратце, include добавляет параметры (из файла, на который указывает) к описанным в smb.conf, при этом при совпадении переопределяются опции, указанные в smb.conf ранее строки include = /path/to/file; параметры, указанные после, остаются неизменными. Параметр config file, напротив, заменяет собой smb.conf, переопределяя при совпадении все, что ниже него по тексту конфига. Подробнее о параметрах и внутренних переменных (с примерами), можно поглядеть в официальной документации проекта Samba.

Пример из жизни. Есть файловый сервер, на котором две шары: public и private, и три клиента: pc1, pc2, pc3, каждый из которых должен иметь доступ к некоторым ресурсам: pc1 - к public, pc2 - к private, pc3 - к public и private. Чтобы это реализовать, потребуются вышеописанные опции. Итак, содержимое конфигов: 

smb.conf: 

 ##for pc2
config file  = /etc/samba/smb.conf-%m
   workgroup = WORK
   server string = %h server
   netbios name = server
   dns proxy = no
   log file = /var/log/samba/log.full
   log level = 1
   max log size = 10000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = share
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   invalid users = root
[public]
        path = /public
        comment = Public Resource 
        guest ok = yes
        browseable = yes
        writable = yes
        force user = nobody
        force create mode = 0666
        force directory mode = 0777

##for pc3
include = /etc/samba/smb-share.conf-%m

smb.conf-pc2:

   log file = /var/log/samba/log.private

   syslog = 0 

[private]
        path = /private
        comment = Private Resource
        guest ok = yes
        browseable = yes
        writable = yes
        force user = nobody
        force create mode = 0666
        force directory mode = 0777 

 smb-share.conf-pc3:

[private]
        path = /private
        comment = Private Resource
        guest ok = yes
        browseable = no
        writable = yes
        force user = nobody
        force create mode = 0666
        force directory mode = 0777

Такая конфигурация предоставляет по умолчанию всем пользователям одну шару public. Фишка рассматриваемых параметров в том, что они срабатывают только при нахождении файла, указанного их аргументом. Отсутствие файла не является ошибкой конфигурирования - информации в лог не пишется, сам параметр игнорируется.
Таким образом, только когда к файловому серверу подключаются клиенты с NetBIOS-именами pc2 и pc3 (или с заданными IP-адресами, если используется переменная %I), срабатывают, соответственно, config file и include. В первом случае клиент pc2 видит одну шару private (плюс его действия начинают записываться в отдельный лог-файл log.private с увеличенным loglevel), во втором - клиент pc3 видит две шары - private и public и для него используются настройки из основного smb.conf.

VK.com birthdays export

Экспорт информации о днях рождения контактов из vk.com с последующим импортом в Google Calendar - тут. Проверено, работает.

KDE SC 4.8 + multiply monitors

Забавная бага (или фича?) словилась на сабжевых кедах при настройке работы с двумя мониторами. Мониторы увиделись, kde-шной утилитой настроились как общий рабочий стол. Однако вне зависимости от комбинаций выставленных галочек в разделе конфигурации поведения окон при мультимониторной конфигурации все окна вели себя так, как будто у меня один большой монитор, а не два отдельных - распахивались сразу на оба монитора или центровались между ними по центру.

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

Debian + Windows domain

Годится не только для debian-based дистрибутивов, но, думаю, и для большинства Unix-систем, где есть samba, kerberos и winbind. Задачка несложная, ввести рабочую станцию (или сервер, неважно) в домен Active Directory и получить возможность авторизации доменных пользователей как графически, так и по ssh. Мне для успешной настройки потребовались пакеты samba, winbind, krb5-user, krb5-config, nscd. Необходимые для доменной авторизации пользователей модули PAM (например, pam_winbind) были установлены автоматически как зависимости.

Исходные данные: имеется домен example.org (win2k3), рабочая станция user-test (Debian Sid), Администратор домена admin, пользователь домена user. В качестве системного DNS используются контроллеры домена (директивы nameserver в resolv.conf или dns-nameserver в interfaces).
Необходимые правки конфигов:
smb.conf:

[global]
workgroup = EXAMPLE
netbios name = user-test
server string = test debian pc
security = ADS
preferred master = no
disable spoolss = Yes
show add printer wizard = No
idmap config * : range = 15000-20000
#winbind separator = +
winbind use default domain = Yes
template shell = /bin/bash
use sendfile = Yes
realm = example.org

log file = /var/log/samba/log.full
load printers = no
printing = bsd
printcap name = /dev/null

krb5.conf:

[libdefaults]
        default_realm = EXAMPLE.ORG
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true
[realms]
        EXAMPLE.ORG = {
                kdc = dc1.example.org
                kdc = dc2.example.org
                admin_server = dc1.example.org
        }
[domain_realm]
        .example.org = EXAMPLE.ORG
        example.org = EXAMPLE.ORG
[login]
        krb4_convert = true
        krb4_get_tickets = false

nsswitch.conf:
#passwd:         compat
passwd:         files winbind
#group:          compat
group:          files winbind
#shadow:         compat
shadow:         files winbind
#hosts:          files dns
hosts:          files dns winbind

pam.d/common-auth:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

pam.d/common-password:

password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_winbind.so use_authtok try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

pam.d/common-account:

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_winbind.so
account requisite                       pam_deny.so
account required                        pam_permit.so

pam.d/common-session:

session         required                pam_mkhomedir.so skel=/etc/skel umask=0022
session         sufficient              pam_unix.so
session         sufficient              pam_sufficient.so

После правки коифигов и перезапуска сервисов присоединяемся к домену, предварительно синхронизировав время с контроллером домена (net time set dc1.example.org):

net ads join -Uadmin
admin's password:
Using short domain name -- EXAMPLE 

Joined 'USER-TEST' to realm 'EXAMPLE.COM'

Проверим успешность ввода с помощью wbinfo:

root@user-test:~# wbinfo -t
checking the trust secret for domain EXAMPLE via RPC calls succeeded

Команды wbinfo -u и wbinfo -g должны показать список пользователей и групп Active Directory.

Squid cache peer proxy

Краткая справка о том, как настроить простейший каскадный (cache-peer) прокси. Все настройки прописываются в squid.conf:

http_port 3128  ## ждем подключения клиентов на этот порт
acl myuser src 192.168.1.100 ## даем доступ для заданных рабочих станций
http_access allow myuser ## активируем описанный выше доступ
cache_peer 192.168.1.254   parent  3128  7 no-digest no-query allow-miss ## описываем вышестоящий (родительский) прокси-сервер, куда следует перенаправлять запросы
never_direct allow myuser ## запрещаем прямые (в обход parent proxy) запросы от заданных рабочих станций

Если все сделано верно, в cache.log после перезапуска squid-а должна появиться следующая запись:

2013/01/11 14:01:51| Configuring 192.168.1.254 Parent 192.168.1.254/3128/7
2013/01/11 14:01:51| Ready to serve requests.

Теперь на рабочей станции 192.168.1.100 в настройках, например, браузера выставляем IP и порт этого squid и получаем рабочий каскадный прокси.