воскресенье, 19 апреля 2015 г.

Дополнительный NAT при отладке juniper

Не часто, зато регулярно приходится иметь дело со всякими умными железками. Причем решаемые задачи от хрестоматийно простых, до "этого сделать нельзя, но очень надо". Так и в этот раз, после двух- или трехлетнего перерыва нужно сделать конфиг для Juniper SRX-100 (версия "B", который с маленькой памятью). Задача осложнена тем, что нужно заранее сделать и быстро-быстро переставить (больница, режим работы круглосуточный простои крайне не желательны). Нужно делать стенд и отлаживать. Ресурсов для деланья оного стенда нет, можно сгородить только половину от желаемого. С созданием source-nat проблем никаких. В результате имеем подключенный к внутренней сети девайс, который можно использовать в качестве дефолтового шлюза (один из интерфейсов вытолкнули наружу, правда через "лишний чужой" NAT). Прописали его на одном компе и погоняли. Все гладко. Надо настроить destination-nat, там полтора десятка разных пробросов, их, собственно и хочется погонять. Условием работы desination nat является использование того-же устройства в качестве default gateway (пакеты приходят с мира, имея настоящий обратный адрес, на который и уходят ответы сервера). Поскольку все те сервисы, которые надобно отладить, используют совершенно другой ip в качестве дефолта, отладка остановилась. Единственный выход - сделать доп. трансляцию адресов с тем, чтоб source-address в пакете был заменен на адрес интерфейса маршрутизатора. Вот этот конфиг, вернее его кусочки и приведем. На самом деле все оказалось не просто, а очень просто.
Раздел system, тут ничего интересного, приведен полностью на всякий случай.

version 11.2R4.3;
system {
    host-name gw1;
    time-zone Asia/Bangkok;
    root-authentication {
        encrypted-password "онтутбыл"; ## SECRET-DATA
    }
    name-server {
        208.67.222.222;
        208.67.220.220;
        8.8.8.8;
        77.88.8.8;
    }
    services {
        ssh;
        web-management {
            http {
                interface vlan.0;
            }
            https {
                system-generated-certificate;
                interface vlan.0;
            }
        }
    }
    syslog {
        archive size 100k files 3;
        user * {
            any emergency;
        }
        file messages {
            any critical;
            authorization info;
        }
        file interactive-commands {
            interactive-commands error;
        }
    }
    max-configurations-on-flash 5;
    max-configuration-rollbacks 5;
    license {
        autoupdate {
            url https://ae1.juniper.net/junos/key_retrieval;
        }
    }
    ntp {
        peer 10.0.0.3;
    }

}

Интерфейсы, даже вычистим серединку для экономии места. Пока стоит один внешний, все остальное в switching.

interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                address 91.201.11.82/29;
            }
        }
    }
    fe-0/0/1 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }

....
    fe-0/0/7 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input deny-ssh;
                }
            }
        }
    }
    vlan {
        unit 0 {
            family inet {
                address 10.0.0.26/23;
            }
        }
    }

Роутинг и пр. Так же на всякий случай

}
snmp {
    community public {
        authorization read-only;
    }
}
routing-options {
    static {
        route 0.0.0.0/0 next-hop 91.201.11.81;
    }
}
protocols {
    stp;
}

Адресную книгу и правила firewall приводить нет смысла. А вот и собственно NAT.

    nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
            rule-set untrust-to-trust {
                from zone untrust;
                to zone trust;
                rule source-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
        destination {
            pool d-rdp2 {
                address 10.0.0.2/32 port 3389;
            }
            rule-set D-NAT {
                from zone untrust;      
                rule rdp2 {             
                    match {             
                        destination-address 91.201.11.82/32;
                        destination-port 3390;
                    }                   
                    then {              
                        destination-nat pool d-rdp2;
                    }                   
                }                       
            }                           
        }                               
    }                                   
    policies {                          
        from-zone trust to-zone untrust {
            policy trust-to-untrust {   
                match {                 
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone trust {
            policy local2-acc {
                match {
                    source-address any;
                    destination-address local2;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.0;
            }
        }
        security-zone untrust {
            interfaces {
                fe-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                            ssh;
                        }
                    }
                }
            }
        }
    }
}

Розовым цветом выделен "дополнительный NAT", ради которого вся писанина. Никаких дополнительных policy не нужно! Теперь пакеты прошедшие destination NAT, проходят еще и source NAT, и приходят  на терминальный сервер с 10.0.0.26 (адрес интерфейса), что позволяет потихоньку проверять устанавливаемые правила пробросов не мешая всему остальному.


понедельник, 13 апреля 2015 г.

FireBird backup

Есть (реальность, данная в самых пренеприятных ощущениях) медицинская программа (Арена, она же Аметист, она же Колибри и еще пара -- тройка ипостасей). Живет она на Win2008R2 (на виртуалке) на движке FireBird. Задача на самом деле простая - нужно ее сохранять родными средствами раз в сутки и иметь достаточное количество копий на случай развала базы. Запускаем по рабочим дням ежедневный скриптик. 

MD %systemroot%\temp\arenabackup
set now=%TIME:~0,-3%
set now=%now::=%
set now=%now: =0%
set now=%DATE:~-4%%DATE:~3,2%%DATE:~0,2%_%now%
"C:\Program Files\Firebird\Firebird_2_5\bin\gbak" -b "C:\arena\DB\arena.Gdb" "%systemroot%\temp\arenabackup\%now%.Gbk" -user sysdba -password masterkey -v -y "%systemroot%\temp\arenabackup\%now%.txt"
"C:\Program Files (x86)\7-Zip\7z.exe" a W:\day\%now%bak.zip %systemroot%\temp\arenabackup*

RD %systemroot%\temp\arenabackup /S/Q

И раз в месяц еще и месячный, для верности

MD %systemroot%\temp\arenabackup
set now=%TIME:~0,-3%
set now=%now::=%
set now=%now: =0%
set now=%DATE:~-4%%DATE:~3,2%%DATE:~0,2%_%now%
"C:\Program Files\Firebird\Firebird_2_5\bin\gbak" -b "C:\arena\DB\arena.Gdb" "%systemroot%\temp\arenabackup\%now%.Gbk" -user sysdba -password masterkey -v -y "%systemroot%\temp\arenabackup\%now%.txt"
"C:\Program Files (x86)\7-Zip\7z.exe" a W:\mounth\%now%bak.zip %systemroot%\temp\arenabackup*
RD %systemroot%\temp\arenabackup /S/Q

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


В соответствующем /etc/cron.d/local есть такие строчки:

22 4 * * 1-5  root find /home/storage/onecopy/arenadb/day -ctime +10 -delete
22 5 15 * *  root find /home/storage/onecopy/arenadb/month -ctime +180 -delete


пятница, 27 марта 2015 г.

От VirtualBox к KVM Часть 2


В первой части все что нужно было попробовано. консоль работает, usb2 работает. Чего хочется. А хочется для рабочей станции (пробы) быстро и из командной строки перебрасывать VM-ки, и, для серверного исполнения иметь по возможности простой рецепт миграции с VirtualBox на KVM. Для рабочей станции нас устроит NAT и локальная консоль, для сервера обязательно VNC и сетевой мост. Так же полезно иметь возможность динамического подключения usb - устройств. Тут полезно прочитать общий рецепт по приготовлению гостевых систем. И еще один совершенно подходящий был найден.
Все что ниже... сыровато

Рабочая станция.

  • Берем готовую VM от VirtualBox и преобразуем ее в формат qcow2 (это просто).
qemu-img convert -f vdi -O qcow2 myvm.vdi myvm.qcow2
  • И создаем домен.
virt-install \
              --name nameof \
              --connect qemu:///system \
              --graphics vnc,port=5901 \
              --os-variant win7 \

              --ram 768 \

              --vcpus=1 \
              --disk /path/to/image/myvm.qcow2,cache=none,format=qcow2 \
              --import \
              --network network=default,model=e1000,mac=11:22:33:44:55:66 \
              --controller=usb2 \

  • Можно заходить в GUI и пользоваться. Вопрос про консоль.
Дальше просто черновик

Сервер

  • Готовим сетевую инфраструктуру (добавляем и активируем бридж). Для сервера (статическое определение интерфейсов без модного ныне network-manager)
  • Исходно имеем /etc/network/interfaces выглядит примерно так.

cat <<EOF | sudo tee -a /etc/network/interfaces
auto br0
iface br0 inet dhcp
  bridge_ports eth0
EOF

sudo initctl start network-intarface INTARFACE=br0



  • Из командной строки создаем домен libvirtd с заданными свойствами (поддержка usb 2.0, доступ к консоли посредством vnc и сеть в том виде, в котором нам нужно.)

virt-install \
              --name nameof \
              --connect qemu:///system \
              --graphics vnc,port=5901 \
              --os-variant win7 \

              --ram 768 \
              --vcpus=1 \
              --disk /path/to/image/myvm.qcow2,cache=none,format=qcow2 \
              --import \
              --network bridge=br0,model=e1000,mac=11:22:33:44:55:66 \
              --controller=usb2 \


  • Старт и стоп полученного домена.
  • Копирование на ходу (снимки).
  • Динамическое добавление устройств usb.
  • Клонирование

воскресенье, 22 марта 2015 г.

Правильно шарим CUPS-принтер через Samba

Есть достаточно большая сеть в которой более сотни LTSP-клиентов, к которым подключено сотня же с небольшим принтеров. Тут же и нормальные компы со своими принтерами (все Xubuntu 14.04), есть сетевые принтеры. И в качестве десерта 2 виндовых терминальных сервера (Windows 2008R2 и пожилой Windows 2003), с которых на эти самые принтеры нужно печатать. Суть проблемы такова - часто происходит ошибка при выборе принтера "не по умолчанию" и пользователи выбирают не тот... Наиболее часто это происходит в начале списка, получается что все принтеры на букву "a"  должны иметь ограничительные списки (это самый минимум). Что касается Линукса - проблем никаких, пишем тупо списки доступа через web-интерфейс CUPS, при этом нет разницы между локальными и удаленными пользователями - просто имя и все. Удобно. При печати с виндового сервера непосредственно в CUPS (подключение через http://, ipp://, ipps://) так красиво не получается, в CUPS передается что-то такое, чего я в логах и найти не смог, ну и доступ, конечно же не предоставляется (все зависит тут от версии винды, встречались упоминания о том, что в ряде случаев передается совершенно нормальное имя).  Как вариант попадалось Client 19 (номер подключения по RDP) - информативненько... Для 2008 сервера почти наверняка можно просто указать имя и ничего более не делать (это имя видится в логах), а вот для 2003 берем бубен... Пробуем засунуть Самбу между CUPS-ом и Виндой, чтоб они друг об друга не шоркались... В smb.conf в глобальной секции

### Globals for printing
# Do not (!) load all printers from CUPS

   load printers = no
   printcap = cups
   printing = CUPS

И опишем принтер
########## Printing ##########

[printers]
   comment = Some Printers
   path = /var/spool/samba
   printable = yes

[adm_3]
    path = /var/spool/samba/
    browseable = yes
    printable = yes
    use client driver = yes
    printer name = adm_3

Теперь на виндовом сервере добавляем этот принтер, добавляем который с указанием типа принтера и в названии "_" поменялось на "-" примерно так (легко догадаться что подключаем-то мы как раз CUPS-овый принтер, а не тот, что так заботливо создавали, но без "лишнего" принтера этот трюк почему-то не удается...)

Без проблем ставим "родной" pcl-ный драйвер. Еще важно. Нужно пользователям (для которых это все делается) прибиндить какой--либо ресурс с этого сервера в качестве сетевого диска, и установить атрибут "восстанавливать при входе в систему". И вот тогда мы можем использовать имя пользователя в Самбе для указания разрешенного пользователя в CUPSе. Принцип простой - пользователь зашел на терминальный сервер, при входе подключился диск, и, как следствие, пользователь залогинился в Самбу. При обращении к принтеру у него будет нормальное имя. И еще замечание. И виндовый сервер и Samba работают как stndalone (нет доменной структуры). Лишний принтер (пока) единственный. Просто оказалось достаточным ограничить доступ к единственному "неудачному" принтеру и проблема снялась. За 2008 пока не брался -- народ мышкой более осознано тыкает, проблема не так остра. Очень надеюсь что в будущем удастся добиться существенно большей логической ясности.

воскресенье, 15 марта 2015 г.

Нестандартное разрешение монитора в Xubuntu 14.04

Материнка из не самых старых "Intel descktop board" + монитор LG IPS234. Мать, как теперь это модно, заточена под Win8x, при установке Xubuntu на роскошном широкоэкранном мониторе имеем скромные 1024x768 с искривлением пропорций. Понятно что надо ручками поправить.  Материал для размышлений есть тут.Порядок действий получился такой.
  • Выясняем что более всего нравится монитору (например жмем кнопки на нем пока не признается) - этот просит 1920x1080 -- хороший вариант.
  • Предполагаем что 60 Гц, может можно и что-то более, но мне как-то так захотелось (собственно можно проверить при желании)
  • Запускаем cvt и выясняем что там за секретные цифирки нам нужны.

vik@lh-inf-1:~/ips$ cvt 1920 1080 60
# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
  • Теперь имя выхода, на котором "висит" монитор, его знает xrandr (запускаем без аргументов и смотрим что там про что. Наш выход оказался VGA1). Пробуем в ручном режиме 

xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
xrandr  --addmode VGA1 1920x1080_60.00
xrandr  --output VGA1 --mode 1920x1080_60.00
Получилось.

  • Делаем файл /opt/rc.local


#!/bin/bash

# for analog!
echo "XRANDR" | logger
/usr/bin/xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
/usr/bin/xrandr  --addmode VGA1 1920x1080_60.00
/usr/bin/xrandr  --output VGA1 --mode 1920x1080_60.00
exit 0
  • и ссылочку на него в /etc/lightdm.d/lightdm.conf
[SeatDefaults]
display-setup-script=/opt/rc.local
  • В заключение  заходим в setup (давим F2) и в разделе "питание" разрешаем управление ACPI со стороны OS (иначе яркость не восстанавливается при пробуждении).





четверг, 12 марта 2015 г.

Делаем доступ по XDMCP и VNC на Ubuntu-сервере (Xubuntu desktop)

Задача

Цепляться к экрану и клаве/мышке сервера, в том числе получать greeter при отсутствии пользователя. Это в принципе может быть применимо и для настольных компьютеров для организации "удаленного помошника". Хорошо бы еще иметь возможность открывать новые сессии отдельно от "локального" пользователя при помощи второго vnc-сервера. Ну и XDMCP лишним не будет (соседняя секция в том же конфиг-файле, на сколько это представляется "на входе").

Пути.

Пользовать надо x11vnc (дает физический экран, а не сессию). Есть сумасшедшая инструкция http://linux-sunxi.org/VNC Переписываем ее с изменениями, по факту, она стала еще короче!
sudo apt-get install x11vnc
sudo x11vnc -storepasswd /etc/x11vnc.pass
 
и вводим какой-либо пароль «от дурака»

создаем (см. дополнение про Xubuntu 18.04 в конце) /etc/init/x11vnc.conf
и в него пишем (там собственно 1 длинная строка, ее можно копипастить): 
start on login-session-start
script
/usr/bin/x11vnc -xkb -auth /var/run/lightdm/root/:0 -noxrecord -noxfixes -noxdamage -rfbauth /etc/x11vnc.pass -forever -shared -bg -rfbport 5900 -o /var/log/x11vnc.log
end script


запускаем start x11vnc

И обычная remmina способна прицепиться. В конфиге только параметры производительности и адрес. Если юзер залогинен — получаем его сессию. Если нет — логин скрин и логинимся. При этом на физическом экране начинает отображаться наша сессия, мы же «железо» перехватываем. X11vnc теперь у нас взлетает на автомате по загрузке.

Доводим до ума настройки lightdm

Нужно убрать гостевой вход и список существующих пользователей.
создаем (обычно он уже есть, но в нем только заголовок секции) файл /etc/lightdm/lightdm.conf.d/10-xubuntu.conf

В нем должно быть вот чего:

[SeatDefaults]
user-session=xubuntu
allow-guest=false
greeter-hide-users=true
greeter-show-manual-login=true

Можно еще попробовать убрать кнопочку питания, для этого в файле /etc/lightdm/lightdm-gtk-greeter-ubuntu.conf
находим строку вида 
indicators=~language;~session;~power
обычно последняя. И убираем ';~power'

Второй сервер и XDMCP.

Работает крайне нестабильно... Смотрим дополнения.


Дополнение 27 января 2016

Для толстых LTSP-клиентов получился совсем особый путь.

Дополнение 25 февраля 2016

Установка x2go.

Дополнение 13 ноября 2019 (с изменениями от 28 ноября 2020)

Для Xubuntu 18.04 и 20.04 вместо /etc/init/x11vnc.conf создаем /lib/systemd/system/x11vnc.service 

[Unit]
Description=x11vnc remote desktop server
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared
Restart=on-failure

[Install]
WantedBy=multi-user.target

Делаем симлинк 
ln -s /lib/systemd/system/x11vnc.service /etc/systemd/system/multi-user.target.wants
Ну и используем соотв. команды типа service x11vnc start [enable status]

Дополнение от 12 июня 2021 для Xubuntu 20.04

[Unit]
Description=x11vnc service
After=display-manager.service network.target syslog.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -forever -display :0 -auth guess -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared
ExecStop=/usr/bin/killall x11vnc
Restart=on-failure

[Install]
WantedBy=multi-user.target




среда, 11 марта 2015 г.

Отсылка почтовых сообщений при помощи nullmailer с использованием yandex.ru

Исходные данные: 
Xubuntu 14.04 (64 разряда, сервер, должно подойти ко всем вариантам установки).

Нужно отсылать диагностику по почте. Ставить для этого скромного занятия postfix или что-то подобное -- из пушки по воробьям. Пробуем прикрутить nullmailer, как самый простой MTA . 

Новый ящик.

Сначала заводим новый почтовый ящик с каким-либо  корявым-прикорявым логином, чтоб ни кому в голову оно само не запало. типа gy76545ghh@yandex.ru, пароль примерно такой же запоминающийся. Настраиваем Thanderbird и проверяем вновь созданный ящик на предмет настроек и пр. Видим, что нам нужен smtp.yandex.ru с портом 465 (ssl/tls).  

Ставим и настраиваем nullmailer. 

Собственно установка  sudo apt-get install nullmailer. На вопросы установочного скрипта можно ввести любую непустую строку, потом поправим как должно быть. Никакие mailutils не ставим. Будем пользовать sendmail для отсылки почты.  Теперь в файл /etc/nullmailer/remotes  пишем 
smtp.yandex.ru  smtp --port=465 --user=gy76545ghh@yandex.ru --pass=пароль --ssl
Пробуем отослать пробное письмо ls | sendmail -f gy76545ghh@yandex.ru destination@addres.dom Должны его получить, и получить соответствующие записи /var/log/mail.log. Вот собственно таким способом, таская с собой -f gy76545ghh@yandex.ru и будем отсылать письма. Если не указывать исходящий адрес, Яндекс просто откажется принимать сообщение. В принципе можно подсмотреть вот тут и -f с собой не таскать... Не совсем корректно, но лучше не придумалось  - вот вся рецептура

# 1) Rename the original sendmail binary:
$ mv /usr/sbin/sendmail /usr/sbin/sendmail-bin

# 2) Create and edit a script called sendmail:
$ touch /usr/sbin/sendmail
$ chmod 755 /usr/sbin/sendmail
Edit the sendmail script file and paste this content:

#!/bin/bash

/usr/sbin/sendmail-bin  -f  `cat /etc/nullmailer/forced-from`  $@ </dev/stdin

Что еще полезно сделать. В файле /etc/nullmailer/adminaddr указать тот же gy76545ghh@yandex.ru. В результате вся рутовая и пр. диагностическая почта будет идти "от себя к себе". Яндекс не ругается и позволяет сделать правила пересылки по полю "от кого". Правила пересылки достаточно кривые, но работают.

Итого.

Из плюсов. Усилий по установке и настройке самый минимум. Можно даже не иметь нормального DNS-имени для хоста, все едино работать будет. Минусы. Алиасов нет, отсылка только на один адрес за раз, если что-то чуть-чуть отличается от тривиального, нужно городить свой скрипт, даже простой mdadm в лет не заработал. На очереди как раз задача по одолению оного mdadm (или установка postfix :-)).

Добавлено 20150804

Вместо переименования "родного" sendmail можно положить "свой" скрипт в /usr/local/sbin/. Пока проверено под Гентой, должно работать и под *buntu.

Добавлено 20190520

Несколько рабочих конфиг-файлов

/etc/nullmailer/adminaddr - мой обычный адрес на гмыле.
/etc/nullmailer/defaultdomain - файл нулевой длины
/etc/nullmailer/forced-from - содержит gy76545ghh@yandex.ru
/etc/nullmailer/me - содержит gy76545ghh@yandex.ru

/etc/nullmailer/remotes содержит  строку
smtp.yandex.ru  smtp --port=465 --user=gy76545ghh@yandex.ru --pass=gy76545ghhpassword --ssl

/etc/mailname - имя машины типа my-serv

фрагмент /etc/mdadm/mdadm.conf
                                                                                
# instruct the monitoring daemon where to send mail alerts                      
MAILADDR viktorkuzmin@гмыл
MAILFROM gy76545ghh@yandex.ru

  
фрагмент /etc/cron.d/local

SHELL=/bin/bash                                                                 
MAILFROM=gy76545ghh@yandex.ru
MAILTO=viktorkuzmin@гмыл
LANG=en_US.UTF-8

/usr/sbin/sendmail (исполняемый)

#! /bin/bash

/usr/sbin/sendmail.bin -f  `cat /etc/nullmailer/forced-from`  $@ </dev/stdin

Неожиданное продолжение от 20210204